{"api_version":"1","generated_at":"2026-08-22T16:59:51+00:00","cve":"CVE-2023-53645","urls":{"html":"https://cve.report/CVE-2023-53645","api":"https://cve.report/api/cve/CVE-2023-53645.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2023-53645","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2023-53645"},"summary":{"title":"bpf: Make bpf_refcount_acquire fallible for non-owning refs","description":"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->rb, 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 <0f> 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   <TASK>\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/","state":"PUBLISHED","assigner":"Linux","published_at":"2025-10-07 16:15:47","updated_at":"2026-08-04 10:19:16"},"problem_types":["CWE-416"],"metrics":[{"version":"3.1","source":"nvd@nist.gov","type":"Primary","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.8","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","data":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/d906d1b940b9dbf0a3e821d6b32a51c369273d91","name":"https://git.kernel.org/stable/c/d906d1b940b9dbf0a3e821d6b32a51c369273d91","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/7793fc3babe9fea908e57f7c187ea819f9fd7e95","name":"https://git.kernel.org/stable/c/7793fc3babe9fea908e57f7c187ea819f9fd7e95","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2023-53645","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53645","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d2dcc67df910dd85253a701b6a5b747f955d28f5 d906d1b940b9dbf0a3e821d6b32a51c369273d91 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d2dcc67df910dd85253a701b6a5b747f955d28f5 7793fc3babe9fea908e57f7c187ea819f9fd7e95 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.4","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.4 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.4.4 6.4.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.5 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[{"cve_year":"2023","cve_id":"53645","vulnerable":"1","versionEndIncluding":"","cpe1":"cpe","cpe2":"2.3","cpe3":"o","cpe4":"linux","cpe5":"linux_kernel","cpe6":"*","cpe7":"*","cpe8":"*","cpe9":"*","cpe10":"*","cpe11":"*","cpe12":"*","cpe13":"*"}],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2023","cve_id":"53645","cve":"CVE-2023-53645","epss":"0.001430000","percentile":"0.040610000","score_date":"2026-08-05","updated_at":"2026-08-06 00:00:37"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["kernel/bpf/helpers.c","kernel/bpf/verifier.c","tools/testing/selftests/bpf/progs/refcounted_kptr.c","tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"d906d1b940b9dbf0a3e821d6b32a51c369273d91","status":"affected","version":"d2dcc67df910dd85253a701b6a5b747f955d28f5","versionType":"git"},{"lessThan":"7793fc3babe9fea908e57f7c187ea819f9fd7e95","status":"affected","version":"d2dcc67df910dd85253a701b6a5b747f955d28f5","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["kernel/bpf/helpers.c","kernel/bpf/verifier.c","tools/testing/selftests/bpf/progs/refcounted_kptr.c","tools/testing/selftests/bpf/progs/refcounted_kptr_fail.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.4"},{"lessThan":"6.4","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.4.*","status":"unaffected","version":"6.4.4","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"6.5","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.4.4","versionStartIncluding":"6.4","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.5","versionStartIncluding":"6.4","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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->rb, 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 <0f> 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   <TASK>\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/"}],"metrics":[{"cvssV3_1":{"baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"}}],"providerMetadata":{"dateUpdated":"2026-08-04T09:15:53.909Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/d906d1b940b9dbf0a3e821d6b32a51c369273d91"},{"url":"https://git.kernel.org/stable/c/7793fc3babe9fea908e57f7c187ea819f9fd7e95"}],"title":"bpf: Make bpf_refcount_acquire fallible for non-owning refs","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2023-53645","datePublished":"2025-10-07T15:19:43.738Z","dateReserved":"2025-10-07T15:16:59.659Z","dateUpdated":"2026-08-04T09:15:53.909Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2025-10-07 16:15:47","lastModifiedDate":"2026-08-04 10:19:16","problem_types":["CWE-416"],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9},{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9}]},"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.4","versionEndExcluding":"6.4.4","matchCriteriaId":"6AB81046-CB69-4115-924C-963B37C41385"}]}]}]},"legacy_mitre":{"record":{"CveYear":"2023","CveId":"53645","Ordinal":"1","Title":"bpf: Make bpf_refcount_acquire fallible for non-owning refs","CVE":"CVE-2023-53645","Year":"2023"},"notes":[{"CveYear":"2023","CveId":"53645","Ordinal":"1","NoteData":"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->rb, 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 <0f> 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   <TASK>\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/","Type":"Description","Title":"bpf: Make bpf_refcount_acquire fallible for non-owning refs"}]}}}