CVE-2026-23249
Analyzed Analyzed - Analysis Complete
Null Pointer Dereference in Linux XFS Btree Revalidation

Publication date: 2026-03-18

Last updated on: 2026-05-21

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-18
Last Modified
2026-05-21
Generated
2026-06-16
AI Q&A
2026-03-18
EPSS Evaluated
2026-06-15
NVD
EUVD
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 6.13 (inc) to 6.18.16 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.6 (exc)
linux linux_kernel From 6.8 (inc) to 6.12.75 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's XFS filesystem code, specifically in the functions that repair and revalidate two btrees related to free space and inode allocation.

During the repair process, two btrees (BNOBT and CNTBT) are revalidated by calling the function xchk_allocbt() twice. The first call nullifies a cursor needed by the second call, which leads to a null pointer dereference and a kernel crash.

The root cause is that after the first btree revalidation fails due to corruption, the cursor for the second btree is deleted (nullified), but the code does not check for this before attempting to revalidate the second btree, causing the crash.

The fix involves checking for a null cursor before revalidating the second btree and marking the repair as incomplete if the first tree is corrupt, preventing the crash.

Impact Analysis

This vulnerability can cause the Linux kernel to crash due to a null pointer dereference when repairing corrupted XFS filesystem metadata.

Such a crash can lead to system instability, potential data loss, or denial of service if the filesystem repair process is triggered.

Systems relying on XFS filesystems may experience unexpected reboots or failures during filesystem maintenance operations.

Compliance Impact

I don't know

Detection Guidance

I don't know

Mitigation Strategies

I don't know

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-23249. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart