VulnerabilityPublished 18 Mar 2026Updated 5 Nov 2026

CVE-2026-23249: Linux kernel · xfs: check for deleted cursors when revalidating two btrees

Affects Linux kernelSource CVE Database V5

Compare

Not known to be exploited · fixed in d69de525bc7ab27713342080bf50826df3f6a68f : update Linux kernel when convenient.

Data as of 5 Nov 2026, 21:49 UTC

Severity

Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

Thin evidence

One scorer or none

Exploitation: No evidence of active exploitation and no public proof of concept
Automatable: Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact: Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-11-05.

Patch

Available – fixed in d69de525bc7ab27713342080bf50826df3f6a68f, b04baa848c0543b240b1bd8aecff470382f6f154, 5991e96f2ae82df60a3e4ed00f3432d9f3502a99 +1

Exploitation evidence

Disclosed: evidence found.
CVE published 18 Mar 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 5 Nov 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponized: A Metasploit exploit module or Exploit-DB entry exists (Metasploit scanner modules do not count), or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade Linux kernel to d69de525bc7ab27713342080bf50826df3f6a68f, b04baa848c0543b240b1bd8aecff470382f6f154, 5991e96f2ae82df60a3e4ed00f3432d9f3502a99 or 55e03b8cbe2783ec9acfb88e8adb946ed504e117.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ dbfbf3bdf639a20da7d5fb390cd2e197d25aa418, < d69de525bc7ab27713342080bf50826df3f6a68f	Fixed in d69de525bc7ab27713342080bf50826df3f6a68f
LinuxLinux	Affected ≥ dbfbf3bdf639a20da7d5fb390cd2e197d25aa418, < b04baa848c0543b240b1bd8aecff470382f6f154	Fixed in b04baa848c0543b240b1bd8aecff470382f6f154
LinuxLinux	Affected ≥ dbfbf3bdf639a20da7d5fb390cd2e197d25aa418, < 5991e96f2ae82df60a3e4ed00f3432d9f3502a99	Fixed in 5991e96f2ae82df60a3e4ed00f3432d9f3502a99
LinuxLinux	Affected ≥ dbfbf3bdf639a20da7d5fb390cd2e197d25aa418, < 55e03b8cbe2783ec9acfb88e8adb946ed504e117	Fixed in 55e03b8cbe2783ec9acfb88e8adb946ed504e117
LinuxLinux	Affected =6.8	Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: xfs: check for deleted cursors when revalidating two btrees The free space and inode btree repair functions will rebuild both btrees at the same time, after which it needs to evaluate both btrees to confirm that the corruptions are gone. However, Jiaming Zhang ran syzbot and produced a crash in the second xchk_allocbt call. His root-cause analysis is as follows (with minor corrections): In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first for BNOBT, second for CNTBT). The cause of this issue is that the first call nullified the cursor required by the second call. Let's first enter xrep_revalidate_allocbt() via following call chain: xfs_file_ioctl() -> xfs_ioc_scrubv_metadata() -> xfs_scrub_metadata() -> `sc->ops->repair_eval(sc)` -> xrep_revalidate_allocbt() xchk_allocbt() is called twice in this function. In the first call: /* Note that sc->sm->sm_type is XFS_SCRUB_TYPE_BNOPT now */ xchk_allocbt() -> xchk_btree() -> `bs->scrub_rec(bs, recp)` -> xchk_allocbt_rec() -> xchk_allocbt_xref() -> xchk_allocbt_xref_other() since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to &sc->sa.cnt_cur. Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call chain: xfs_alloc_get_rec() -> xfs_btree_get_rec() -> xfs_btree_check_block() -> (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter is true, return -EFSCORRUPTED. This should be caused by ioctl$XFS_IOC_ERROR_INJECTION I guess. Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this function, *curpp (points to sc->sa.cnt_cur) is nullified. Back to xrep_revalidate_allocbt(), since sc->sa.cnt_cur has been nullified, it then triggered null-ptr-deref via xchk_allocbt() (second call) -> xchk_btree(). So. The bnobt revalidation failed on a cross-reference attempt, so we deleted the cntbt cursor, and then crashed when we tried to revalidate the cntbt. Therefore, check for a null cntbt cursor before that revalidation, and mark the repair incomplete. Also we can ignore the second tree entirely if the first tree was rebuilt but is already corrupt. Apply the same fix to xrep_revalidate_iallocbt because it has the same problem.

References

Community reviews

Loading reviews…