CVE-2026-31455

What it actually does

This is a local Linux kernel flaw in the XFS filesystem unmount path. During XFS unmount, the kernel could push the Active Item List while inode garbage collection and background inode reclaim were still running. Those background workers could dirty, reinsert, abort, or free inodes while unmount cleanup was processing them, creating a race condition with use-after-free-style memory corruption potential. Because the CVSS vector requires local privileges, exploitation generally requires an attacker who can already execute code locally and influence XFS filesystem mount/unmount activity. Successful exploitation could affect kernel memory integrity and may lead to kernel crash, denial of service, or potentially local privilege escalation depending on kernel configuration, timing, and exploitability of the race.

Why it matters to the business

Systems using affected Linux kernels with XFS filesystems may be exposed to local attacks that can destabilize hosts or potentially let a low-privileged user gain elevated control. The most likely operational impact is unexpected kernel crashes or service interruption during XFS unmount activity, especially on systems with frequent mount lifecycle operations such as servers, build systems, container hosts, storage nodes, and test infrastructure. There is no current KEV listing, no ransomware association, very low EPSS, and no known exploit maturity reported, so urgency is lower than for internet-facing remote vulnerabilities; however, because the issue is in the kernel, successful exploitation has high consequence and should be remediated through normal kernel update cycles.

How an attack unfolds

An attacker first needs local access with enough privileges to run code and influence filesystem activity involving XFS. They would attempt to create conditions where XFS inode garbage collection and background reclaim remain active while an XFS filesystem is being unmounted. By repeatedly creating, modifying, deleting, and forcing cleanup of files on an XFS filesystem while triggering unmount or teardown operations, the attacker attempts to win the race between AIL flushing, inodegc, and reclaim work. If the race is hit, the kernel may access inode-related structures after they have been freed or while they are in an inconsistent state. In practical terms, this may produce a kernel Oops, panic, filesystem shutdown, or memory corruption. Turning that corruption into reliable privilege escalation would require kernel-specific exploitation work and is not currently known to be mature for this CVE.

How to fix it

Upgrade to a Linux kernel release that includes the upstream XFS fix which stops inode garbage collection and cancels background reclaim before pushing the AIL during unmount. If using a vendor-supported distribution, apply the vendor kernel security update rather than attempting to cherry-pick patches manually. Because no exact fixed package versions were provided, confirm remediation from the relevant distribution advisory, kernel changelog, or vendor errata for CVE-2026-31455. After installing the patched kernel, reboot affected systems so the fixed kernel is actually running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting who can mount or unmount filesystems, avoiding untrusted workloads on hosts using XFS, and minimizing frequent XFS mount/unmount operations by untrusted users or automation.

How to confirm the fix worked

Confirm the running kernel version is the patched vendor release, not only that the package is installed. On Linux systems, compare `uname -r` with the version listed in the vendor advisory and verify the system was rebooted after the update. Check whether XFS is in use with tools such as `findmnt -t xfs`, `/proc/mounts`, or `lsblk -f`. Review kernel package changelogs or distribution errata for an XFS fix referencing `xfs_unmount_flush_inodes`, stopping `inodegc`, cancelling `m_reclaim_work`, or CVE-2026-31455. For exposure validation, identify systems that both run affected kernels and mount XFS filesystems. For functional validation in non-production environments, perform controlled XFS mount/unmount testing and confirm there are no kernel Oops, KASAN, lockdep, or XFS shutdown messages during teardown.

Typical attack path

1. Obtain local code execution on a Linux system using an affected kernel.
2. Identify or create access to an XFS filesystem whose mount lifecycle can be influenced.
3. Generate inode churn through repeated file creation, modification, deletion, sync, and cleanup activity.
4. Trigger or race XFS unmount operations while inode garbage collection and background reclaim work may still be active.
5. Attempt to cause a race during AIL flushing and inode reclaim.
6. Use the resulting kernel memory corruption for denial of service or, if a reliable exploit exists, local privilege escalation.

How to detect it

Look for evidence of kernel instability or memory corruption associated with XFS unmount activity. Useful log sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, audit logs for mount and unmount activity, crash dump infrastructure such as kdump/vmcore, and endpoint telemetry showing local users or automation repeatedly creating, deleting, syncing, mounting, and unmounting XFS filesystems. Search for kernel Oops, panic, KASAN use-after-free, slab corruption, general protection faults, or XFS forced-shutdown messages near unmount events. Correlate these with local user sessions, container jobs, CI workloads, loop device usage, namespace activity, or unusual mount/umount frequency. Because there are no public exploit indicators and the bug is a race in kernel filesystem teardown, detection is behavioral and forensic rather than signature-based. Absence of these artifacts does not prove the vulnerability was not attempted, because failed race attempts may leave little or no evidence.

• xfs_unmount_flush_inodes
• xfs_inodegc
• m_reclaim_work
• xfs_inodegc_set_reclaimable
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• kernel BUG at fs/xfs
• XFS: Internal error
• XFS: log I/O error
• XFS: Filesystem has been shut down
• Oops:
• general protection fault
• kernel panic
• BUG: unable to handle kernel NULL pointer dereference
• umount xfs

What your security team should do

• Inventory Linux systems using XFS and prioritize those that allow local users, CI jobs, containers, build workloads, or untrusted code execution.
• Apply vendor kernel updates that include the XFS unmount ordering fix and reboot systems into the patched kernel.
• Prioritize patching multi-user systems, container hosts, virtualization hosts, storage servers, and systems with frequent filesystem mount/unmount automation.
• Until patched, restrict local access and administrative capabilities that allow mounting or unmounting filesystems, especially for untrusted users or workloads.
• Monitor kernel logs for XFS-related crashes, use-after-free reports, filesystem shutdowns, or Oops/panic events around unmount activity.
• If suspicious crashes are observed, preserve kernel logs, crash dumps, audit logs, and workload history before rebooting or rebuilding the host.
• Track vendor advisories because exact fixed versions vary by distribution and kernel maintenance branch.