CVE-2023-53645

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Make bpf_refcount_acquire fallible for non-owning refs<br /> <br /> This patch fixes an incorrect assumption made in the original<br /> bpf_refcount series [0], specifically that the BPF program calling<br /> bpf_refcount_acquire on some node can always guarantee that the node is<br /> alive. In that series, the patch adding failure behavior to rbtree_add<br /> and list_push_{front, back} breaks this assumption for non-owning<br /> references.<br /> <br /> Consider the following program:<br /> <br /> n = bpf_kptr_xchg(&amp;mapval, NULL);<br /> /* skip error checking */<br /> <br /> bpf_spin_lock(&amp;l);<br /> if(bpf_rbtree_add(&amp;t, &amp;n-&gt;rb, less)) {<br /> bpf_refcount_acquire(n);<br /> /* Failed to add, do something else with the node */<br /> }<br /> bpf_spin_unlock(&amp;l);<br /> <br /> It&amp;#39;s incorrect to assume that bpf_refcount_acquire will always succeed in this<br /> scenario. bpf_refcount_acquire is being called in a critical section<br /> here, but the lock being held is associated with rbtree t, which isn&amp;#39;t<br /> necessarily the lock associated with the tree that the node is already<br /> in. So after bpf_rbtree_add fails to add the node and calls bpf_obj_drop<br /> in it, the program has no ownership of the node&amp;#39;s lifetime. Therefore<br /> the node&amp;#39;s refcount can be decr&amp;#39;d to 0 at any time after the failing<br /> rbtree_add. If this happens before the refcount_acquire above, the node<br /> might be free&amp;#39;d, and regardless refcount_acquire will be incrementing a<br /> 0 refcount.<br /> <br /> Later patches in the series exercise this scenario, resulting in the<br /> expected complaint from the kernel (without this patch&amp;#39;s changes):<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110<br /> Modules linked in: bpf_testmod(O)<br /> CPU: 1 PID: 207 Comm: test_progs Tainted: G O 6.3.0-rc7-02231-g723de1a718a2-dirty #371<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0xbc/0x110<br /> Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02 00 75 94 48 c7 c7 e0 13 d2 82 c6 05 4e 64 f6 02 01 e8 64 a3 5c ff 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7<br /> RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082<br /> RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000<br /> RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680<br /> RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7<br /> R10: ffffed1021722edc R11: 746e756f63666572 R12: ffff88810027d388<br /> R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048<br /> FS: 00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> bpf_refcount_acquire_impl+0xb5/0xc0<br /> <br /> (rest of output snipped)<br /> <br /> The patch addresses this by changing bpf_refcount_acquire_impl to use<br /> refcount_inc_not_zero instead of refcount_inc and marking<br /> bpf_refcount_acquire KF_RET_NULL.<br /> <br /> For owning references, though, we know the above scenario is not possible<br /> and thus that bpf_refcount_acquire will always succeed. Some verifier<br /> bookkeeping is added to track "is input owning ref?" for bpf_refcount_acquire<br /> calls and return false from is_kfunc_ret_null for bpf_refcount_acquire on<br /> owning refs despite it being marked KF_RET_NULL.<br /> <br /> Existing selftests using bpf_refcount_acquire are modified where<br /> necessary to NULL-check its return value.<br /> <br /> [0]: https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/