CVE-2026-43365

What it actually does

This flaw is an improper validation/handling issue in the Linux kernel XFS filesystem code. When an XFS superblock does not specify a log stripe unit, the kernel can use an undersized in-memory log roundoff value of 512 bytes even when the filesystem log sector size is larger, such as 4096 bytes. That mismatch can lead to torn writes, XFS log corruption, failed log recovery, and filesystems becoming unmountable. The primary impact is availability loss and possible limited filesystem metadata integrity impact. Although the CVSS vector indicates network reachability, practical exploitation generally depends on an attacker being able to induce a system to mount or process a crafted or malformed XFS filesystem image, block device, virtual disk, removable media, or storage volume.

Why it matters to the business

Systems that mount affected XFS filesystems can suffer filesystem corruption, boot or mount failures, storage service outages, and operational downtime. Workloads using XFS for application data, virtual machine images, container hosts, backup media, or shared storage may require emergency recovery procedures and could experience delayed service restoration. The vulnerability is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, so broad internet exploitation is unlikely; however, the operational impact can be severe where untrusted disk images or externally supplied storage volumes are mounted automatically.

How an attack unfolds

An attacker prepares an XFS filesystem image or block device with a malformed or fuzzed on-disk superblock, specifically one that results in an absent log stripe unit while using a larger log sector size. The attacker then needs a path to make a vulnerable Linux system mount or recover that filesystem, such as through a malicious disk image, VM image, removable drive, backup artifact, storage snapshot, or another workflow that automatically mounts supplied filesystems. During mount or log recovery, the kernel calculates an inadequate log roundoff value, causing improper handling of log writes or recovery. This can produce torn-write detection, CRC failures, failed log-tail location, log mount failure, and potentially an unmountable XFS filesystem. Successful exploitation is most useful as a denial-of-service or disruption technique rather than for confidentiality compromise.

How to fix it

Apply Linux kernel updates from the relevant operating system or distribution vendor once the fix for this XFS issue is available. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor advisories for the installed kernel stream. Until patched, reduce exposure by avoiding automatic mounting of untrusted XFS filesystems, disk images, VM images, removable media, and externally supplied block devices. Mount untrusted images only in isolated, disposable analysis environments. Review and restrict automount services, udev rules, backup-restore workflows, forensic ingestion pipelines, and virtualization/container workflows that may mount user-supplied storage. For existing affected filesystems, maintain tested backups and use vendor-supported XFS recovery tools such as xfs_repair only after preserving evidence and snapshots where incident response or recovery is required.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for the XFS log roundoff issue, not merely that an updated package is installed but pending reboot. Check the active kernel with uname -r and compare it against the distribution advisory once published. Reboot into the patched kernel where required. Validate exposure reduction by confirming that untrusted filesystem images and removable media are not automatically mounted. On test systems, use controlled regression testing with malformed XFS images only in isolated environments to confirm that the system no longer corrupts logs or fails recovery due to an undersized log roundoff calculation. Review dmesg, journalctl, and kernel logs after mounting XFS volumes for absence of XFS torn-write, CRC, log recovery, and log mount failure messages.

Typical attack path

1. Create or obtain a malformed XFS filesystem image or block device whose superblock omits the log stripe unit while using a larger filesystem log sector size.
2. Deliver the crafted image or storage object through a path that a target system may mount or inspect, such as a VM disk, container build artifact, backup, removable device, forensic sample, or cloud/block-storage volume.
3. Trigger mounting, automounting, filesystem probing, or recovery of the crafted XFS volume on a vulnerable Linux kernel.
4. Cause the XFS kernel code to use an undersized log roundoff value during log handling.
5. Induce log corruption, torn-write/CRC errors, failed log recovery, mount failure, or an unmountable filesystem.
6. Leverage the resulting outage to disrupt services dependent on that filesystem or host.

How to detect it

Look for evidence that a system mounted or attempted to mount a malformed XFS filesystem shortly before corruption or mount failure. Primary log sources are kernel ring buffer logs, systemd journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, storage/udev logs, hypervisor or image-ingestion logs, backup/restore job logs, and EDR telemetry showing mount, losetup, qemu-nbd, guestmount, xfs_repair, or xfs_db activity. Search for XFS messages indicating torn writes, CRC failures, failed log tail discovery, log recovery failure, or log mount failure. Correlate these events with recent attachment of removable media, loop devices, NBD devices, virtual disks, cloud block volumes, downloaded disk images, backup restores, or forensic samples. Investigate any sequence where an untrusted or newly attached block device was mounted as XFS and kernel logs then show XFS log corruption or recovery errors. Because no public exploit-specific payload signature is available, detection should focus on filesystem error artifacts, suspicious mount sources, and operational context rather than network indicators.

• XFS (
• ): Torn write (CRC failure) detected at log block
• Truncating head block from
• failed to locate log tail
• log mount/recovery failed: error -74
• log mount failed
• Mounting V5 Filesystem
• Ending clean mount
• xfs_repair
• xfs_db
• xfs_info
• mount -t xfs
• losetup
• qemu-nbd
• guestmount
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Prioritize patch tracking for Linux systems that mount XFS filesystems in production, especially storage servers, virtualization hosts, container hosts, backup infrastructure, and systems that process external disk images.
• Disable or tightly control automounting of removable media, externally supplied block devices, VM images, and backup images until patched.
• Inventory systems using XFS with commands such as findmnt -t xfs, lsblk -f, and mount, then prioritize those with critical workloads or untrusted storage ingestion paths.
• Review virtualization, CI/CD, backup, forensic, and support workflows for any process that mounts customer-supplied or third-party disk images, and move those workflows into sandboxed environments.
• Monitor kernel logs for XFS log corruption, CRC failures, torn-write messages, and mount recovery failures that may indicate attempted exploitation or naturally corrupted filesystems.
• Ensure recent, offline or immutable backups exist for critical XFS-backed data before performing repair operations.
• If suspicious XFS corruption appears after mounting an untrusted image or device, preserve the image/device metadata and kernel logs before running repair tools.
• Track vendor advisories for exact fixed kernel versions and schedule reboots so the patched kernel is actually active.