CVE-2026-31454

What it actually does

This is a Linux kernel use-after-free flaw in the XFS filesystem log item push path. In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the kernel drops the AIL lock to perform buffer I/O, creating a race window where the log item can be reclaimed by background reclaim or the dquot shrinker. The code then dereferences lip->li_ailp after the object may have been freed. A local attacker who can trigger the affected XFS code paths may be able to cause kernel memory corruption, leading to denial of service and potentially local privilege escalation or arbitrary kernel-code execution, depending on exploitability and kernel hardening.

Why it matters to the business

Systems running affected Linux kernels with XFS filesystems may be vulnerable to a local attack that can crash the host or potentially allow a lower-privileged user or compromised process to gain full control of the operating system. The risk is highest on multi-user Linux servers, shared compute platforms, container hosts, CI/build workers, and systems where untrusted local users or workloads can exercise filesystem activity. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has a very low, flat EPSS score, so broad opportunistic exploitation is currently less likely than targeted local exploitation or reliability impact.

How an attack unfolds

An attacker first needs local code execution with low privileges on a Linux system using an affected kernel and XFS. They then attempt to generate filesystem and quota/log activity that reaches the vulnerable XFS log item push callbacks while also inducing reclaim or shrinker activity. If timed successfully, the relevant log item can be freed after the AIL lock is dropped but before the later dereference of lip->li_ailp. The immediate result may be a kernel oops, panic, or system hang. With sufficient control over heap layout and timing, an attacker may attempt to turn the use-after-free into controlled kernel memory corruption for privilege escalation. No public exploit or active exploitation is currently indicated by the supplied intelligence.

How to fix it

Upgrade to a Linux kernel version that includes the upstream XFS fix that saves the AIL pointer before dropping the AIL lock in the affected push callbacks. Because exact fixed package versions were not provided, use the kernel packages from the relevant Linux distribution vendor advisory once available, or a stable kernel release that contains the fix for CVE-2026-31454. Reboot into the patched kernel after installation; merely installing a kernel package is not sufficient if the host continues running the old kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, applying least privilege to service accounts, disabling unnecessary interactive access, and prioritizing affected multi-user or container-host systems. If XFS is not required on a system, consider avoiding use of XFS for newly deployed filesystems until patched, but filesystem migration is usually more disruptive than kernel patching and should not be the primary remediation.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, is updated to a vendor release containing the fix. On Linux systems, compare `uname -r` with the distribution advisory or package changelog for the fixed kernel. Review kernel package changelogs for references to CVE-2026-31454, XFS AIL locking, xfs_inode_item_push(), xfs_qm_dquot_logitem_push(), or saving ailp before dropping the AIL lock. Confirm whether XFS is in use with standard filesystem inventory commands such as `findmnt -t xfs` or equivalent configuration management data. After patching and rebooting, verify that affected hosts are no longer running the vulnerable kernel and monitor for absence of related kernel oops, KASAN, or panic messages under normal filesystem activity.

Typical attack path

1. Obtain local low-privileged execution on a Linux host running an affected kernel.
2. Confirm or infer that XFS is in use, especially on writable filesystems with active metadata/log traffic.
3. Generate XFS inode or quota-related filesystem activity to exercise xfs_inode_item_push() or xfs_qm_dquot_logitem_push().
4. Create memory pressure or reclaim activity to increase the likelihood that the log item is freed during the lock-drop window.
5. Trigger the stale dereference of lip->li_ailp after the object has been freed.
6. Cause a kernel crash or attempt to shape the use-after-free into local privilege escalation.

How to detect it

Look for evidence of attempted or successful local exploitation by reviewing kernel logs, crash dumps, audit records, and endpoint telemetry. Useful sources include journald, dmesg, /var/log/kern.log, /var/log/messages, /var/crash, kdump/vmcore data, auditd, EDR process telemetry, and workload scheduler logs on shared compute systems. Search for kernel oops, panic, general protection fault, slab corruption, KASAN use-after-free reports, or warnings involving XFS functions such as xfs_inode_item_push(), xfs_qm_dquot_logitem_push(), AIL, log items, dquot reclaim, or shrinker activity. Correlate crashes with local users, containers, jobs, or processes performing heavy XFS metadata operations, quota operations, or memory-pressure activity shortly before the fault. There are no supplied network indicators and exploitation is local, so network IDS is unlikely to provide direct detection. Absence of crash artifacts does not prove absence of exploitation, especially if a successful privilege-escalation exploit avoided triggering a visible panic.

• CVE-2026-31454
• xfs_inode_item_push
• xfs_qm_dquot_logitem_push
• lip->li_ailp
• li_ailp
• xfs: save ailp before dropping the AIL lock
• use-after-free
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• XFS
• AIL
• dquot shrinker
• xfsaild
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/vmcore

What your security team should do

• Prioritize patching Linux systems that run XFS and allow local users, untrusted jobs, containers, CI workloads, or shared compute access.
• Track vendor advisories for exact fixed kernel package versions and ensure systems reboot into the patched kernel after installation.
• Inventory XFS usage across Linux fleets to scope exposure and prioritize remediation.
• Apply compensating controls where patching is delayed: restrict local access, reduce untrusted workload placement, and enforce least privilege for service and user accounts.
• Monitor kernel logs for XFS-related oops, panic, use-after-free, KASAN, or lock/reclaim anomalies, especially on systems with untrusted local workloads.
• Because current EPSS is very low, flat, and there is no KEV or known ransomware linkage, treat this as a high-impact local privilege-escalation risk rather than an internet-scale emergency unless local threat exposure is high.