CVE-2026-43053

What it actually does

This is a Linux kernel XFS filesystem crash-consistency flaw in extended attribute inactivation. During deletion/inactivation of an inode with node-format extended attributes, XFS could cancel child attribute blocks in the journal while leaving parent node pointers to those cancelled blocks until a later attribute-fork truncation transaction. If the filesystem log shuts down or the system crashes in that narrow window, log recovery can replay an inode whose attribute fork still points to blocks that were intentionally not replayed. On the next mount or recovery pass, XFS may follow stale attribute-tree pointers and fail metadata verification, producing metadata corruption errors and forcing filesystem shutdown or repair. The impact is availability only: no direct confidentiality or integrity impact is indicated, but affected XFS filesystems can become unavailable until repaired.

Why it matters to the business

Systems using XFS can suffer filesystem mount failures, forced shutdowns, service outages, and recovery windows if the crash window is hit. Because exploitation requires local access, specific filesystem state, and a difficult timing condition, broad exploitation is unlikely; the low EPSS score, no known exploit maturity, and absence from the CISA Known Exploited Vulnerabilities catalog support lower Internet-scale urgency. However, affected production hosts that rely on XFS for databases, logs, virtual machine storage, container storage, or persistent application data should still treat this as operationally important because a successful trigger can cause downtime and potentially require offline filesystem repair.

How an attack unfolds

An attacker would need local code execution or an account capable of manipulating files on an XFS filesystem. They would create or modify files so that their extended attributes use XFS node-format attribute structures, then trigger inode inactivation, commonly by removing files or otherwise causing cleanup of those extended attributes. The attacker would then need to induce or coincide with a log shutdown, crash, forced reset, storage fault, or other abrupt interruption after child attribute blocks are invalidated but before the attribute fork is fully truncated. If the timing succeeds, log recovery can leave an attribute btree root or parent node pointing to unreplayed child blocks. On the next mount or recovery processing, XFS attempts to verify those blocks, detects metadata corruption, logs XFS verification errors, and may shut down the filesystem or require xfs_repair before normal operation resumes.

How to fix it

Apply a Linux kernel update that includes the XFS fixes for safe attribute dabtree inactivation. Because no exact fixed kernel versions were provided, use the security advisory and patched kernel packages from the relevant Linux distribution or kernel vendor, then reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads from writing to XFS filesystems, avoiding unnecessary use of extended attributes by untrusted users, and preventing non-administrative users from inducing crashes, forced resets, or storage disruptions. Operationally, ensure recent backups exist for critical XFS filesystems and plan maintenance windows for any systems that may require offline filesystem checking or repair.

How to confirm the fix worked

Confirm that hosts are running a kernel build that contains the vendor’s fix for this XFS issue; checking package changelogs, distribution errata, or kernel commit backports is more reliable than version comparison alone. After patching, reboot and verify the active kernel with standard OS tooling such as uname and package-manager queries. Identify exposure by checking whether systems use XFS filesystems, especially for critical persistent data. Review boot, kernel, and journal logs for XFS metadata verification failures or forced shutdowns. For filesystems that have shown related errors, perform an offline read-only check with xfs_repair -n first, then follow vendor guidance for full repair if corruption is reported. Successful validation means the patched kernel is active, XFS filesystems mount cleanly, and logs no longer show related xfs_da3_node or attribute-tree verification failures after recovery events.

Typical attack path

1. Obtain local access with the ability to create, modify, and delete files on an XFS filesystem.
2. Create files with enough extended attributes to force node-format XFS attribute storage rather than simple inline attributes.
3. Trigger inode inactivation by deleting/unlinking or otherwise removing files with those extended attributes.
4. Attempt to cause or wait for a log shutdown, system crash, forced reset, storage interruption, or similar failure during the vulnerable transaction window.
5. Allow the system to reboot or remount so XFS log recovery processes the affected inode and attribute fork.
6. Cause or observe XFS metadata verification failure, filesystem shutdown, mount failure, or a requirement to run xfs_repair.

How to detect it

Look for signs of XFS metadata verification failure or log recovery problems rather than a single definitive exploit marker. Relevant log sources include kernel ring buffer output, systemd journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, boot logs, crash logs, and storage/platform event logs showing resets or faults around the same time. Search for XFS messages involving metadata corruption, xfs_da3_node_read_verify, xfs_da_read_buf, metadata I/O error, log shutdown, forced shutdown, unmount-and-repair messages, and xlog_recover_process_iunlinks. Correlate these with recent local file activity involving extended attributes, large-scale file deletion, cleanup jobs, container or VM storage churn, package managers, backup tools, or untrusted local users. Because this is a high-complexity local crash-window issue, absence of a named exploit tool or network signature is expected; detection should focus on filesystem error artifacts, suspicious local timing around crashes, and repeated attempts to induce abrupt shutdowns while manipulating XFS-backed files.

• Metadata corruption detected at xfs_da3_node_read_verify
• xfs_da3_node block
• Unmount and run xfs_repair
• metadata I/O error in "xfs_da_read_buf
• xlog_recover_process_iunlinks
• XFS (
• Metadata corruption detected
• First 128 bytes of corrupted metadata buffer
• error 117
• xfs_attr3_node_inactive
• xfs_attr_inactive
• xfs_trans_binval
• xfs_da3_node_verify
• log shutdown
• Filesystem has been shut down

What your security team should do

• Inventory Linux systems using XFS and prioritize patching for servers where filesystem unavailability would cause significant service impact.
• Apply vendor-provided kernel updates containing the XFS attr dabtree inactivation fix and reboot to ensure the patched kernel is active.
• Review recent kernel, boot, and system journal logs for XFS metadata corruption, xfs_da3_node verification failures, metadata I/O errors, forced shutdowns, or instructions to run xfs_repair.
• Treat any affected XFS filesystem with related errors as potentially unstable; preserve evidence, validate backups, and run xfs_repair according to operational change controls.
• Restrict local access and untrusted workloads on systems that cannot be patched promptly, especially workloads that can create many files and extended attributes on XFS.
• Ensure crash-consistency and recovery procedures are tested for critical XFS-backed services, including backup restoration and offline repair procedures.