CVE-2023-53645
Fecha de publicación:
07/10/2025
*** 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(&mapval, NULL);<br />
/* skip error checking */<br />
<br />
bpf_spin_lock(&l);<br />
if(bpf_rbtree_add(&t, &n->rb, less)) {<br />
bpf_refcount_acquire(n);<br />
/* Failed to add, do something else with the node */<br />
}<br />
bpf_spin_unlock(&l);<br />
<br />
It&#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&#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&#39;s lifetime. Therefore<br />
the node&#39;s refcount can be decr&#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&#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&#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/
Gravedad CVSS v3.1: ALTA
Última modificación:
03/02/2026
