CVE-2023-53836

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