CVE-2023-53645
published 2025-10-07CVE-2023-53645: In the Linux kernel, the following vulnerability has been resolved: bpf: Make bpf_refcount_acquire fallible for non-owning refs This patch fixes an incorrect…
PriorityP339high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.14%
4.1th percentile
In the Linux kernel, the following vulnerability has been resolved:
bpf: Make bpf_refcount_acquire fallible for non-owning refs
This patch fixes an incorrect assumption made in the original
bpf_refcount series [0], specifically that the BPF program calling
bpf_refcount_acquire on some node can always guarantee that the node is
alive. In that series, the patch adding failure behavior to rbtree_add
and list_push_{front, back} breaks this assumption for non-owning
references.
Consider the following program:
n = bpf_kptr_xchg(&mapval, NULL);
/* skip error checking */
bpf_spin_lock(&l);
if(bpf_rbtree_add(&t, &n->rb, less)) {
bpf_refcount_acquire(n);
/* Failed to add, do something else with the node */
}
bpf_spin_unlock(&l);
It's incorrect to assume that bpf_refcount_acquire will always succeed in this
scenario. bpf_refcount_acquire is being called in a critical section
here, but the lock being held is associated with rbtree t, which isn't
necessarily the lock associated with the tree that the node is already
in. So after bpf_rbtree_add fails to add the node and calls bpf_obj_drop
in it, the program has no ownership of the node's lifetime. Therefore
the node's refcount can be decr'd to 0 at any time after the failing
rbtree_add. If this happens before the refcount_acquire above, the node
might be free'd, and regardless refcount_acquire will be incrementing a
0 refcount.
Later patches in the series exercise this scenario, resulting in the
expected complaint from the kernel (without this patch's changes):
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110
Modules linked in: bpf_testmod(O)
CPU: 1 PID: 207 Comm: test_progs Tainted: G O 6.3.0-rc7-02231-g723de1a718a2-dirty #371
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:refcount_warn_saturate+0xbc/0x110
Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02
Affected
7 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.4.4-1 (forky) | linux 6.4.4-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= d2dcc67df910dd85253a701b6a5b747f955d28f5 < d906d1b940b9dbf0a3e821d6b32a51c369273d91 | d906d1b940b9dbf0a3e821d6b32a51c369273d91 |
| linux | linux | >= d2dcc67df910dd85253a701b6a5b747f955d28f5 < 7793fc3babe9fea908e57f7c187ea819f9fd7e95 | 7793fc3babe9fea908e57f7c187ea819f9fd7e95 |
| linux | linux_kernel | >= 0 < 6.4.4-1 | 6.4.4-1 |
| linux | linux_kernel | >= 0 < 6.4.4-1 | 6.4.4-1 |
| linux | linux_kernel | >= 6.4 < 6.4.4 | 6.4.4 |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8LOW
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: bpf: Make bpf_refcount_acquire fallible for non-owning refs
vendor_redhat·2025-10-07·CVSS 7.8
CVE-2023-53645 [HIGH] kernel: bpf: Make bpf_refcount_acquire fallible for non-owning refs
kernel: bpf: Make bpf_refcount_acquire fallible for non-owning refs
In the Linux kernel, the following vulnerability has been resolved:
bpf: Make bpf_refcount_acquire fallible for non-owning refs
This patch fixes an incorrect assumption made in the original
bpf_refcount series [0], specifically that the BPF program calling
bpf_refcount_acquire on some node can always guarantee that the node is
alive. In that series, the patch adding failure behavior to rbtree_add
and list_push_{front, back} breaks this assumption for non-owning
references.
Consider the following program:
n = bpf_kptr_xchg(&mapval, NULL);
/* skip error checking */
bpf_spin_lock(&l);
if(bpf_rbtree_add(&t, &n->rb, less)) {
bpf_refcount_acquire(n);
/* Failed to add, do something else with the node */
}
bpf_spin_unlock(&l);
It
Debian
CVE-2023-53645: linux - In the Linux kernel, the following vulnerability has been resolved: bpf: Make b...
vendor_debian·2023·CVSS 7.8
CVE-2023-53645 [HIGH] CVE-2023-53645: linux - In the Linux kernel, the following vulnerability has been resolved: bpf: Make b...
In the Linux kernel, the following vulnerability has been resolved: bpf: Make bpf_refcount_acquire fallible for non-owning refs This patch fixes an incorrect assumption made in the original bpf_refcount series [0], specifically that the BPF program calling bpf_refcount_acquire on some node can always guarantee that the node is alive. In that series, the patch adding failure behavior to rbtree_add and list_push_{front, back} breaks this assumption for non-owning references. Consider the following program: n = bpf_kptr_xchg(&mapval, NULL); /* skip error checking */ bpf_spin_lock(&l); if(bpf_rbtree_add(&t, &n->rb, less)) { bpf_refcount_acquire(n); /* Failed to add, do something else with the node */ } bpf_spin_unlock(&l); It's incorrect to assume that bpf_refcount_acquire will always succeed
GHSA
GHSA-pw78-hwhh-29v2: In the Linux kernel, the following vulnerability has been resolved:
bpf: Make bpf_refcount_acquire fallible for non-owning refs
This patch fixes an
ghsa_unreviewed·2025-10-07
CVE-2023-53645 [HIGH] CWE-416 GHSA-pw78-hwhh-29v2: In the Linux kernel, the following vulnerability has been resolved:
bpf: Make bpf_refcount_acquire fallible for non-owning refs
This patch fixes an
In the Linux kernel, the following vulnerability has been resolved:
bpf: Make bpf_refcount_acquire fallible for non-owning refs
This patch fixes an incorrect assumption made in the original
bpf_refcount series [0], specifically that the BPF program calling
bpf_refcount_acquire on some node can always guarantee that the node is
alive. In that series, the patch adding failure behavior to rbtree_add
and list_push_{front, back} breaks this assumption for non-owning
references.
Consider the following program:
n = bpf_kptr_xchg(&mapval, NULL);
/* skip error checking */
bpf_spin_lock(&l);
if(bpf_rbtree_add(&t, &n->rb, less)) {
bpf_refcount_acquire(n);
/* Failed to add, do something else with the node */
}
bpf_spin_unlock(&l);
It's incorrect to assume that bpf_refcount_acquire will always su
OSV
CVE-2023-53645: In the Linux kernel, the following vulnerability has been resolved: bpf: Make bpf_refcount_acquire fallible for non-owning refs This patch fixes an in
osv·2025-10-07·CVSS 7.8
CVE-2023-53645 [HIGH] CVE-2023-53645: In the Linux kernel, the following vulnerability has been resolved: bpf: Make bpf_refcount_acquire fallible for non-owning refs This patch fixes an in
In the Linux kernel, the following vulnerability has been resolved: bpf: Make bpf_refcount_acquire fallible for non-owning refs This patch fixes an incorrect assumption made in the original bpf_refcount series [0], specifically that the BPF program calling bpf_refcount_acquire on some node can always guarantee that the node is alive. In that series, the patch adding failure behavior to rbtree_add and list_push_{front, back} breaks this assumption for non-owning references. Consider the following program: n = bpf_kptr_xchg(&mapval, NULL); /* skip error checking */ bpf_spin_lock(&l); if(bpf_rbtree_add(&t, &n->rb, less)) { bpf_refcount_acquire(n); /* Failed to add, do something else with the node */ } bpf_spin_unlock(&l); It's incorrect to assume that bpf_refcount_acquire will always succeed
No detection rules found.
No public exploits indexed.
2025-10-07
Published