CVE-2026-64357

What it actually does

This is a Linux kernel XFS filesystem bug in the exchange-mappings reservation calculation. The kernel adds BMBT and reverse-mapping B-tree overhead to a block-reservation value, but the bounds check is performed against the pre-overhead value rather than the final computed value. If a crafted or extreme XFS exchange-mapping operation causes the final reservation to exceed the unsigned-int limit later used by transaction allocation, the reservation can be truncated or under-sized. The most likely impact is local denial of service through transaction allocation failure, XFS filesystem shutdown, kernel warning/panic, or loss of availability for workloads using the affected XFS filesystem path.

Why it matters to the business

Successful exploitation can disrupt Linux systems that use XFS by causing filesystem errors, forced filesystem shutdown, or kernel instability. This can interrupt applications, containers, databases, file services, or backup workflows that depend on the affected filesystem. Current public risk indicators are low: EPSS is 0.00168, it is not listed in CISA KEV, it is not marked as ransomware-used, and no mature exploit is indicated; however, kernel filesystem bugs should still be remediated through normal patch cycles because impact can be high on systems where untrusted users can write to XFS filesystems.

How an attack unfolds

An attacker first needs local access or another path that lets them create and manipulate files on an affected XFS filesystem. They then attempt to trigger an XFS exchange-mappings operation with file layout characteristics large or complex enough that the metadata reservation, after BMBT and rmapbt overhead are added, exceeds the limit that should have been enforced. Because the vulnerable code checks the earlier reservation value instead of the final computed value, the invalid reservation can proceed into transaction allocation. The resulting under-reservation or integer-size mismatch can cause the XFS transaction path to fail unexpectedly, potentially leading to filesystem shutdown, kernel warnings, or a system crash. This is not expected to be remotely exploitable by itself unless a remote service exposes filesystem write/manipulation capability to an attacker.

How to fix it

Apply a Linux kernel update from the relevant operating system or kernel vendor that includes the XFS fix for the exchmaps reservation limit check. No exact fixed package versions were provided in the input, so use vendor advisories and distribution errata to identify the corrected kernel build for each supported platform. Reboot systems after installing the fixed kernel unless using a vendor-supported live-patching mechanism that explicitly covers this XFS change. Where immediate patching is not possible, reduce exposure by limiting untrusted local users, restricting container or service write access to XFS-backed paths, avoiding workloads that expose arbitrary file-manipulation primitives to untrusted users, and prioritizing patching for multi-user Linux systems, shared hosting, build runners, storage servers, and container hosts using XFS.

How to confirm the fix worked

Confirm exposure by identifying systems running affected Linux kernel builds and using XFS filesystems. Useful checks include `uname -r`, distribution package inventory such as `rpm -q kernel` or `dpkg -l 'linux-image*'`, and filesystem inventory such as `findmnt -t xfs` or `mount | grep ' type xfs '`. Confirm remediation by verifying the running kernel version matches a vendor-fixed build and that the system has rebooted into that kernel. If source-based validation is used, confirm the XFS exchmaps reservation calculation checks the final computed reservation value after overhead is added, not only the original request value. Also review kernel logs after patching to ensure there are no recurring XFS forced-shutdown, transaction allocation, or filesystem corruption messages.

Typical attack path

1. Gain local user access, container access with write access to an XFS-backed path, or control over an application that can create and manipulate files on XFS storage.
2. Identify or target a mounted XFS filesystem where exchange-mapping functionality can be reached.
3. Create files or extents with characteristics intended to inflate XFS metadata reservation overhead.
4. Invoke file mapping/exchange operations that reach the vulnerable XFS exchmaps reservation calculation path.
5. Cause the final reservation value to exceed the intended unsigned-int limit while bypassing the incorrect pre-overhead check.
6. Trigger transaction allocation failure, XFS forced shutdown, kernel warning, or system instability resulting in denial of service.

How to detect it

There is no reliable network indicator for this vulnerability, and successful exploitation may look like an XFS filesystem failure or kernel crash rather than a clearly attributable intrusion. Review host logs and crash artifacts from the period before any reboot or filesystem outage. Primary sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `dmesg`, kdump/vmcore data, and filesystem repair records. Look for XFS forced-shutdown messages, transaction reservation or allocation failures, kernel warnings/panics with stack traces containing XFS exchmaps functions, and repeated file-layout manipulation immediately before the event. If auditd, eBPF, or EDR telemetry is available, correlate suspicious local users, containers, or services performing unusual high-volume file creation, reflink/copy-range, or file extent manipulation on XFS mount points before the crash. Because no public exploit maturity or known threat actor activity is indicated, detection should focus on anomalous local activity and XFS failure artifacts rather than fixed malware signatures.

• xfs_exchmaps_estimate_overhead
• xfs_trans_alloc
• xfs_exchmaps
• XFS: Filesystem has been shut down
• Corruption of in-memory data detected. Shutting down filesystem
• Please unmount the filesystem and rectify the problem
• Internal error xfs_trans_cancel
• WARNING: CPU:
• Kernel panic - not syncing
• BUG: kernel NULL pointer dereference

What your security team should do

• Inventory Linux systems using XFS and correlate them with kernel versions and vendor security advisories for this issue.
• Prioritize remediation for shared, multi-tenant, container-hosting, CI/CD, storage, and application servers where untrusted users or services can write to XFS-backed storage.
• Patch to a vendor-fixed kernel and reboot into the corrected version; do not rely on package installation alone.
• If patching must be delayed, restrict untrusted local access and reduce write/manipulation permissions to XFS-backed paths exposed through applications or containers.
• Monitor kernel and system logs for XFS forced shutdowns, transaction allocation failures, kernel warnings, or crashes involving XFS exchange-mapping code.
• Treat unexplained XFS shutdowns or kernel panics on exposed multi-user systems as potential security events and preserve logs, crash dumps, and filesystem metadata before repair operations where feasible.