CVE-2026-23249
Received Received - Intake
Null Pointer Dereference in Linux XFS Btree Revalidation

Publication date: 2026-03-18

Last updated on: 2026-03-18

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-03-18
Generated
2026-05-07
AI Q&A
2026-03-18
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23249
EUVD
EUVD-2026-12852
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux_kernel xfs *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

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.


How can this vulnerability impact me? :

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.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

I don't know


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart