CVE-2026-31453

What it actually does

This is a Linux kernel use-after-free flaw in the XFS filesystem AIL push path. After xfsaild_push_item() invokes an item push callback, the associated XFS log item can be freed while the AIL lock is temporarily dropped, but later tracepoint handling may still dereference that freed object. A local authenticated attacker who can trigger relevant XFS filesystem activity may be able to turn the stale kernel pointer dereference into a kernel crash or, depending on allocator state, kernel memory corruption that could enable privilege escalation. The CVSS vector is local, low complexity, low privileges required, no user interaction, with high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels with XFS filesystems may be exposed to local denial of service or possible local privilege escalation. The highest-risk environments are multi-user Linux servers, shared compute platforms, container hosts, CI/CD runners, HPC systems, and any workload where untrusted or semi-trusted users can perform filesystem operations on XFS-backed storage. EPSS is currently very low and the issue is not listed in CISA KEV, with no public exploit maturity reported, but the potential impact remains high because successful exploitation occurs in kernel context.

How an attack unfolds

An attacker first needs local access with enough privilege to perform filesystem operations against an XFS-mounted filesystem. They then create pressure on XFS log item handling, inode reclaim, or quota-related reclaim paths so that xfsaild_push_item() invokes an item push callback while the AIL lock may be dropped. During that window, background reclaim or shrinker activity can free the log item. When execution returns, vulnerable tracepoint code may dereference fields from the freed log item. In the simplest case this causes a kernel fault, panic, or system instability. With more control over heap layout and timing, an attacker may attempt to reuse the freed memory with attacker-influenced data to corrupt kernel execution state and escalate privileges. No active exploitation, named threat actors, ransomware use, or KEV listing is currently reported in the provided intelligence.

How to fix it

Upgrade to a Linux kernel build that includes the upstream XFS fix for avoiding dereferences of log items after push callbacks. Because no exact fixed versions were provided, use distribution advisories from the relevant Linux vendor and install the first kernel package that explicitly includes the fix for this issue. Reboot into the patched kernel after installation; merely installing the 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, avoiding shared write access to XFS filesystems, disabling or relocating untrusted workloads from XFS-backed volumes where feasible, and applying least-privilege controls to containers and user namespaces. Consider increasing monitoring for kernel crashes and XFS-related faults until all systems are patched.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a vendor-fixed build. Validate with commands such as uname -r, package manager kernel version checks, and vendor advisory mapping. Check whether XFS is in use with findmnt -t xfs, mount -t xfs, or /proc/mounts. Review change logs or distribution security notices for an XFS fix related to avoiding dereferencing log items after xfsaild_push_item()/iop_push() callbacks. After rebooting, verify that no hosts remain on affected kernel builds and that normal XFS filesystem workloads run without kernel warnings, BUG/Oops messages, or xfsaild crashes.

Typical attack path

1. Gain local authenticated access to a Linux system running an affected kernel.
2. Identify or rely on an XFS-mounted filesystem that the user can exercise through file operations.
3. Generate intensive filesystem metadata activity, such as file creation, deletion, sync, quota, or inode reclaim pressure.
4. Attempt to race XFS AIL push callbacks with reclaim or shrinker activity so a log item is freed while later code still references it.
5. Trigger the stale dereference in the xfsaild/XFS tracepoint path.
6. Cause a kernel crash for denial of service or attempt heap grooming to convert the use-after-free into privilege escalation.

How to detect it

Look for evidence of kernel instability or exploitation attempts on systems using XFS. Primary sources include kernel logs, journald, syslog, dmesg output, crash dumps, kdump/vmcore artifacts, audit logs for local user activity, EDR telemetry for suspicious local privilege escalation behavior, and container/runtime logs on shared hosts. Search for kernel Oops, BUG, panic, KASAN use-after-free, general protection fault, slab corruption, or xfsaild-related crashes, especially if preceded by unusual bursts of filesystem metadata operations from a local user or container. Correlate unexpected reboots or panics with high rates of file creation/deletion, quota operations, sync/fsync activity, or memory pressure on XFS volumes. There are no reliable network indicators for this local kernel issue; detection is primarily host-forensic and log-based.

• xfsaild
• xfsaild_push_item
• iop_push
• xfs_ail_push
• XFS
• BUG: KASAN: use-after-free
• BUG: unable to handle kernel NULL pointer dereference
• general protection fault
• kernel BUG at fs/xfs/
• Oops:
• Kernel panic - not syncing
• use-after-free in xfs
• slab-use-after-free
• fs/xfs/xfs_trans_ail.c
• xfs_dquot
• dquot shrinker
• inode reclaim

What your security team should do

• Inventory Linux systems running XFS filesystems and prioritize multi-user, shared compute, container host, and internet-facing administration environments.
• Patch affected Linux kernel packages using vendor-provided updates and reboot systems into the fixed kernel.
• Because exact fixed versions were not provided, track the issue through distribution advisories and confirm the fix is included in the deployed kernel build.
• Temporarily restrict untrusted local access and untrusted workloads on XFS-backed systems until patching is complete.
• Monitor kernel logs for XFS, xfsaild, KASAN, BUG, Oops, use-after-free, and general protection fault messages.
• Investigate unexpected kernel panics or reboots on XFS systems as potential exploitation attempts or stability symptoms.
• Do not treat the low EPSS score or non-KEV status as a reason to defer patching on systems where untrusted local users or workloads are present.