CVE-2026-43053: Linux Kernel Privilege Escalation Flaw

CVE-2026-43053 Overview

CVE-2026-43053 is a race condition vulnerability in the Linux kernel's XFS filesystem affecting the extended attribute (xattr) dabtree inactivation logic. The flaw resides in xfs_attr3_node_inactive() and xfs_attr_inactive(), where a log shutdown occurring between two non-atomic transaction commits can leave stale parent-to-child pointers on disk. On the subsequent mount, log recovery follows these stale pointers and triggers a metadata verification failure, forcing the filesystem to shut down. The issue is classified under [CWE-367] (Time-of-Check Time-of-Use race condition) and requires local access to trigger.

Critical Impact

A crash window during XFS extended attribute inactivation can leave the filesystem unmountable, requiring xfs_repair intervention to recover.

Affected Products

• Linux Kernel (mainline) prior to the fix commits
• Linux Kernel 2.6.12 release candidates (rc2 through rc5)
• Linux Kernel 7.0 release candidates (rc1 through rc7)

Discovery Timeline

• 2026-05-01 - CVE-2026-43053 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-43053

Vulnerability Analysis

The vulnerability affects XFS inode inactivation when the inode contains node-format extended attributes. During inactivation, xfs_attr3_node_inactive() invalidates child leaf and node blocks via xfs_trans_binval() but intentionally skips removing the corresponding entries from parent node blocks. The original design assumes xfs_attr_inactive() will subsequently truncate the entire attribute fork to zero extents, preventing recovery from ever traversing the stale pointers.

This assumption breaks under log shutdown conditions. If the kernel shuts down the log after the leaf and node block cancellations commit but before the attribute bmap truncation commits, the on-disk state becomes inconsistent. Recovery replays the attribute bmap intact while suppressing replay of the cancelled child blocks, leaving stale or zeroed data on disk.

Root Cause

The root cause is the lack of atomicity between two transaction phases. The cancellation of child blocks and the truncation of the attribute fork must commit together or not at all. The race window between them produces a partially consistent on-disk structure that recovery cannot reconcile.

Attack Vector

Exploitation requires local access and the ability to induce a log shutdown at a precise moment during inode inactivation. On the next mount, xlog_recover_process_iunlinks() retries inactivation and reads the root node through the attribute bmap. The verifier xfs_da3_node_read_verify() rejects the unreplayed or zeroed root block, producing a metadata I/O error at xfs_da_read_buf+0x104/0x190 and forcing an unmount. The fix in commits b854e1c4eff3 and e5a3e3cdd9b3 removes parent entries in the same transaction as the child invalidation, converts the empty root node to a leaf block, and splits attribute fork truncation into two explicit phases with the root invalidation atomically committed alongside the bmap-to-zero truncation.

Detection Methods for CVE-2026-43053

Indicators of Compromise

• Kernel log entries containing Metadata corruption detected at xfs_da3_node_read_verify
• Messages stating metadata I/O error in "xfs_da_read_buf" with error code 117
• Mount-time XFS shutdown messages recommending xfs_repair after an unclean shutdown
• Hex dump of zeroed-out 128-byte metadata buffer in dmesg output following XFS log recovery

Detection Strategies

• Monitor dmesg and /var/log/messages for XFS metadata corruption signatures tied to xfs_da3_node block reads
• Audit kernel versions across the fleet to identify hosts running pre-patch XFS code
• Track filesystem shutdown events from XFS subsystems via journalctl -k -g "XFS"

Monitoring Recommendations

• Forward kernel log messages to a centralized SIEM and alert on XFS metadata verification failures
• Track unexpected filesystem remounts in read-only mode following XFS shutdown events
• Correlate power-loss or hard-reset events with subsequent mount-time XFS recovery failures on systems with heavy xattr usage (for example, SELinux-labeled or Samba ACL-heavy workloads)

How to Mitigate CVE-2026-43053

Immediate Actions Required

• Update the Linux kernel to a stable release that includes commits b854e1c4eff3473b6d3a9ae74129ac5c48bc0b61 and e5a3e3cdd9b3015ae79456c81beebfdbb5246c0f
• Inventory hosts using XFS as the root or data filesystem and prioritize patching nodes that store inodes with large extended attribute sets
• Run xfs_repair on any filesystem that has reported the metadata corruption signature before returning it to production

Patch Information

The fix is upstreamed in two Linux kernel commits available from git.kernel.org. The patches restructure xfs_attr3_node_inactive() to remove parent entries within the same transaction as the child invalidation and split xfs_attr_inactive() into two atomic phases. See the kernel commit b854e1c4eff3 and the kernel commit e5a3e3cdd9b3 for source-level details.

Workarounds

• No supported software workaround eliminates the race; only the upstream patch closes the crash window
• Reduce the probability of triggering the bug by avoiding forced shutdowns and using a UPS on systems with heavy XFS extended attribute workloads
• Maintain tested backups so that any filesystem requiring xfs_repair can be restored without data loss

# Verify the running kernel version and confirm patch presence
uname -r
rpm -q --changelog kernel | grep -E "b854e1c4eff3|e5a3e3cdd9b3"

# After patching, reboot and confirm XFS health
sudo reboot
dmesg | grep -i xfs