Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:[EOL][EOL]bpf, sockmap: Fix skb refcnt race after locking changes[EOL][EOL]There is a race where skb's from the sk_psock_backlog can be referenced[EOL]after userspace side has already skb_consumed() the sk_buff and its refcnt[EOL]dropped to zer0 causing use after free.[EOL][EOL]The flow is the following:[EOL][EOL]  while ((skb = skb_peek(&psock->ingress_skb))[EOL]    sk_psock_handle_Skb(psock, skb, ..., ingress)[EOL]    if (!ingress) ...[EOL]    sk_psock_skb_ingress[EOL]       sk_psock_skb_ingress_enqueue(skb)[EOL]          msg->skb = skb[EOL]          sk_psock_queue_msg(psock, msg)[EOL]    skb_dequeue(&psock->ingress_skb)[EOL][EOL]The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is[EOL]what the application reads when recvmsg() is called. An application can[EOL]read this anytime after the msg is placed on the queue. The recvmsg hook[EOL]will also read msg->skb and then after user space reads the msg will call[EOL]consume_skb(skb) on it effectively free'ing it.[EOL][EOL]But, the race is in above where backlog queue still has a reference to[EOL]the skb and calls skb_dequeue(). If the skb_dequeue happens after the[EOL]user reads and free's the skb we have a use after free.[EOL][EOL]The !ingress case does not suffer from this problem because it uses[EOL]sendmsg_*(sk, msg) which does not pass the sk_buff further down the[EOL]stack.[EOL][EOL]The following splat was observed with 'test_progs -t sockmap_listen':[EOL][EOL]  [ 1022.710250][ T2556] general protection fault, ...[EOL]  [...][EOL]  [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog[EOL]  [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80[EOL]  [ 1022.713653][ T2556] Code: ...[EOL]  [...][EOL]  [ 1022.720699][ T2556] Call Trace:[EOL]  [ 1022.720984][ T2556]  <TASK>[EOL]  [ 1022.721254][ T2556]  ? die_addr+0x32/0x80^M[EOL]  [ 1022.721589][ T2556]  ? exc_general_protection+0x25a/0x4b0[EOL]  [ 1022.722026][ T2556]  ? asm_exc_general_protection+0x22/0x30[EOL]  [ 1022.722489][ T2556]  ? skb_dequeue+0x4c/0x80[EOL]  [ 1022.722854][ T2556]  sk_psock_backlog+0x27a/0x300[EOL]  [ 1022.723243][ T2556]  process_one_work+0x2a7/0x5b0[EOL]  [ 1022.723633][ T2556]  worker_thread+0x4f/0x3a0[EOL]  [ 1022.723998][ T2556]  ? __pfx_worker_thread+0x10/0x10[EOL]  [ 1022.724386][ T2556]  kthread+0xfd/0x130[EOL]  [ 1022.724709][ T2556]  ? __pfx_kthread+0x10/0x10[EOL]  [ 1022.725066][ T2556]  ret_from_fork+0x2d/0x50[EOL]  [ 1022.725409][ T2556]  ? __pfx_kthread+0x10/0x10[EOL]  [ 1022.725799][ T2556]  ret_from_fork_asm+0x1b/0x30[EOL]  [ 1022.726201][ T2556]  </TASK>[EOL][EOL]To fix we add an skb_get() before passing the skb to be enqueued in the[EOL]engress queue. This bumps the skb->users refcnt so that consume_skb()[EOL]and kfree_skb will not immediately free the sk_buff. With this we can[EOL]be sure the skb is still around when we do the dequeue. Then we just[EOL]need to decrement the refcnt or free the skb in the backlog case which[EOL]we do by calling kfree_skb() on the ingress case as well as the sendmsg[EOL]case.[EOL][EOL]Before locking change from fixes tag we had the sock locked so we[EOL]couldn't race with user and there was no issue here.