CVE-2026-43158

What it actually does

This is a Linux kernel XFS filesystem flaw in extended attribute handling. When local extended attributes are added to XFS leaf blocks, the kernel can incorrectly adjust the leaf block free-space map so that free space overlaps the attribute entry array. That inconsistent metadata can place the attribute name/value area below the end of the entries array, triggering kernel assertions or XFS corruption checks and causing the affected filesystem to shut down. Depending on kernel build, runtime checks, and workload, the practical impact is primarily denial of service to the mounted XFS filesystem, with potential metadata corruption risk. The CVSS vector indicates exploitation requires low privileges and no user interaction, and could be reachable through services that allow an authenticated user to create or modify files and extended attributes on XFS-backed storage.

Why it matters to the business

Systems using XFS can experience sudden filesystem shutdowns, application errors, unavailable storage, interrupted workloads, and possible recovery operations if an unprivileged or service-level user can create crafted extended attributes. This is especially relevant for multi-user Linux hosts, container platforms, file-sharing services, CI/build systems, and storage servers where less-trusted users or workloads can write to XFS filesystems. The issue is not currently listed in CISA KEV, has no known exploit maturity reported, and has a low EPSS score that has remained flat over 30 days, but the operational impact can still be high where XFS availability is critical.

How an attack unfolds

An attacker first obtains access to an account, workload, or network-facing service that can write to files on an XFS filesystem and set extended attributes. They then repeatedly create or modify files and set local extended attributes with sizes and ordering that force XFS attribute leaf blocks to grow their entry array. Due to the flawed free-space-map adjustment logic, a later extended attribute insertion can make the leaf block free-space map overlap with the entries array. When XFS validates or continues processing the inconsistent leaf block, the kernel can hit an assertion or corruption condition and force the affected filesystem into shutdown to prevent further damage. If the writable XFS filesystem backs an application, container volume, shared file service, or host directory, this can cause application failures and service disruption.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the XFS fix for extended attribute leaf block free-space-map adjustment. Because no exact fixed package versions were provided, use the fixed kernel versions published by the operating system vendor or distribution maintainer for this CVE. Ensure the fix includes the related XFS changes referenced by the upstream description, including the dependency that fixes attr leaf header freemap.size underflow and the change that resets zero-length freemap entries. After installing the updated kernel, reboot into the patched kernel; simply installing the package is not sufficient if the running kernel remains vulnerable. As temporary risk reduction, restrict untrusted users, containers, and services from writing to XFS-backed paths where possible; limit or disable extended attribute setting through application controls where feasible; reduce write access to shared XFS volumes; and monitor for XFS metadata corruption or forced shutdown messages. For critical XFS filesystems, ensure recent backups and tested recovery procedures are available before and after patching.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor build containing the XFS patch. Validate with commands such as uname -r, distribution package inventory, and vendor advisory/changelog checks for the CVE or XFS attr leaf freemap fix. Inventory mounted filesystems with findmnt -t xfs or mount output to identify systems where exposure matters. Review whether untrusted users, containers, or network services can write to those XFS mount points and set extended attributes. After remediation, reboot and verify the patched kernel is active, then monitor dmesg, journalctl -k, and system logs for absence of recurring XFS assertion, metadata corruption, or forced shutdown messages during normal extended attribute workloads. Where appropriate in non-production, run filesystem stress or regression tests that exercise extended attribute creation on XFS to confirm stability.

Typical attack path

1. Identify a Linux system or service using an XFS-backed writable filesystem.
2. Gain low-privileged local access, container write access, or authenticated access to a service that can create files and set extended attributes on that filesystem.
3. Create files or directories and repeatedly add or modify extended attributes to exercise XFS attribute leaf block growth.
4. Use attribute name and value sizes that cause XFS leaf block free-space entries to become inconsistent with the growing attribute entry array.
5. Trigger XFS metadata validation, assertion, or corruption handling during the extended attribute operation.
6. Cause the affected XFS filesystem to shut down or become unavailable until administrative recovery or remount actions are taken.

How to detect it

To determine whether this may have already been triggered, review kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and centralized log platforms for XFS assertion failures, metadata corruption notices, and forced filesystem shutdowns near times of file or extended attribute activity. Correlate events with auditd, EDR, container runtime, file server, NFS/SMB, application, or system call telemetry showing setxattr, lsetxattr, or fsetxattr activity by untrusted users, service accounts, containers, or network-facing services. Look for repeated use of tools such as setfattr or application components that create many extended attributes. Check for crash dumps, kernel oops/panic records, filesystem remounts, read-only transitions, I/O errors, and service failures following XFS messages. Because this bug can also be triggered by stress or legitimate workloads, treat XFS forced shutdowns plus concentrated extended-attribute activity as suspicious but not definitive without additional context.

• ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t)
• xfs_attr3_leaf_add_work
• xfs_attr_leaf
• xfs_attr3_leaf
• xfs_do_force_shutdown
• Corruption of in-memory data detected. Shutting down filesystem
• Metadata corruption detected at xfs_attr
• XFS: Assertion failed
• XFS: Internal error
• XFS: xfs_do_force_shutdown
• Filesystem has been shut down
• syscall=setxattr
• syscall=lsetxattr
• syscall=fsetxattr
• exe="/usr/bin/setfattr"
• comm="setfattr"

What your security team should do

• Prioritize patching Linux systems that use XFS for shared storage, container volumes, application data, home directories, CI/build workspaces, file servers, or other writeable multi-user locations.
• Reboot systems after kernel updates and verify the running kernel includes the vendor fix.
• Inventory XFS mount points and identify which are writable by untrusted users, containers, or externally reachable services.
• Temporarily restrict write and extended-attribute operations on sensitive XFS-backed paths until patched, especially in multi-tenant or semi-trusted environments.
• Add monitoring for XFS forced shutdown, metadata corruption, and assertion messages in kernel logs.
• Review recent kernel logs for signs of prior XFS shutdowns or corruption events that may indicate attempted or accidental triggering.
• Ensure backups are current for business-critical XFS filesystems and that restoration procedures are tested.
• Because there is no known active exploitation, low EPSS, and no KEV listing, schedule broadly but accelerate remediation where XFS availability is business-critical or exposed to untrusted write activity.