{"id":"CVE-2023-53645","summary":"bpf: Make bpf_refcount_acquire fallible for non-owning refs","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Make bpf_refcount_acquire fallible for non-owning refs\n\nThis patch fixes an incorrect assumption made in the original\nbpf_refcount series [0], specifically that the BPF program calling\nbpf_refcount_acquire on some node can always guarantee that the node is\nalive. In that series, the patch adding failure behavior to rbtree_add\nand list_push_{front, back} breaks this assumption for non-owning\nreferences.\n\nConsider the following program:\n\n  n = bpf_kptr_xchg(&mapval, NULL);\n  /* skip error checking */\n\n  bpf_spin_lock(&l);\n  if(bpf_rbtree_add(&t, &n-\u003erb, less)) {\n    bpf_refcount_acquire(n);\n    /* Failed to add, do something else with the node */\n  }\n  bpf_spin_unlock(&l);\n\nIt's incorrect to assume that bpf_refcount_acquire will always succeed in this\nscenario. bpf_refcount_acquire is being called in a critical section\nhere, but the lock being held is associated with rbtree t, which isn't\nnecessarily the lock associated with the tree that the node is already\nin. So after bpf_rbtree_add fails to add the node and calls bpf_obj_drop\nin it, the program has no ownership of the node's lifetime. Therefore\nthe node's refcount can be decr'd to 0 at any time after the failing\nrbtree_add. If this happens before the refcount_acquire above, the node\nmight be free'd, and regardless refcount_acquire will be incrementing a\n0 refcount.\n\nLater patches in the series exercise this scenario, resulting in the\nexpected complaint from the kernel (without this patch's changes):\n\n  refcount_t: addition on 0; use-after-free.\n  WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110\n  Modules linked in: bpf_testmod(O)\n  CPU: 1 PID: 207 Comm: test_progs Tainted: G           O       6.3.0-rc7-02231-g723de1a718a2-dirty #371\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:refcount_warn_saturate+0xbc/0x110\n  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 \u003c0f\u003e 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7\n  RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082\n  RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000\n  RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680\n  RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7\n  R10: ffffed1021722edc R11: 746e756f63666572 R12: ffff88810027d388\n  R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048\n  FS:  00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  PKRU: 55555554\n  Call Trace:\n   \u003cTASK\u003e\n   bpf_refcount_acquire_impl+0xb5/0xc0\n\n  (rest of output snipped)\n\nThe patch addresses this by changing bpf_refcount_acquire_impl to use\nrefcount_inc_not_zero instead of refcount_inc and marking\nbpf_refcount_acquire KF_RET_NULL.\n\nFor owning references, though, we know the above scenario is not possible\nand thus that bpf_refcount_acquire will always succeed. Some verifier\nbookkeeping is added to track \"is input owning ref?\" for bpf_refcount_acquire\ncalls and return false from is_kfunc_ret_null for bpf_refcount_acquire on\nowning refs despite it being marked KF_RET_NULL.\n\nExisting selftests using bpf_refcount_acquire are modified where\nnecessary to NULL-check its return value.\n\n  [0]: https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/","modified":"2026-03-20T12:33:16.396609Z","published":"2025-10-07T15:19:43.738Z","related":["SUSE-SU-2025:21040-1","SUSE-SU-2025:21052-1","SUSE-SU-2025:21056-1","SUSE-SU-2025:21064-1","SUSE-SU-2025:4057-1","SUSE-SU-2025:4128-1","SUSE-SU-2025:4132-1","SUSE-SU-2025:4140-1","SUSE-SU-2025:4141-1","SUSE-SU-2025:4301-1"],"database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/53xxx/CVE-2023-53645.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/7793fc3babe9fea908e57f7c187ea819f9fd7e95"},{"type":"WEB","url":"https://git.kernel.org/stable/c/d906d1b940b9dbf0a3e821d6b32a51c369273d91"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/53xxx/CVE-2023-53645.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53645"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"d2dcc67df910dd85253a701b6a5b747f955d28f5"},{"fixed":"d906d1b940b9dbf0a3e821d6b32a51c369273d91"},{"fixed":"7793fc3babe9fea908e57f7c187ea819f9fd7e95"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2023-53645.json"}}],"schema_version":"1.7.5"}