CVE-2026-43118

What it actually does

CVE-2026-43118 is a Linux kernel Btrfs log-replay flaw in inode metadata handling. Under a specific sequence involving truncating a file to zero bytes, fsyncing it, creating a new hard link or rename entry, fsyncing the directory, and then experiencing an unclean shutdown, Btrfs can replay the filesystem log incorrectly and preserve the file’s previous non-zero size instead of the intended zero size. The result is filesystem metadata inconsistency after crash recovery, potentially causing stale or unexpected file contents and application-level failures on systems using Btrfs.

Why it matters to the business

The practical risk is operational disruption and data inconsistency after an unexpected reboot or crash on systems using Btrfs. Applications that rely on truncation, log rotation, temporary-file cleanup, package updates, database files, or state-file replacement may observe files that appear larger than expected after recovery. Exploitation requires local privileges and a crash or power-loss condition, and current public exploitation signals are low: EPSS is 0.00112, the 30-day EPSS trend is flat, it is not listed in CISA KEV, and no exploit maturity is reported. Organizations with broad Btrfs usage should still prioritize routine kernel updates because filesystem corruption and recovery issues can create high operational impact even when remote exploitation is unlikely.

How an attack unfolds

An attacker needs local access to a system using Btrfs and the ability to write to a Btrfs-mounted filesystem. They create or modify a file so it has a non-zero size, force it to disk, truncate it to zero bytes, and fsync the file. They then create another directory entry for the same inode, such as with a hard link or rename pattern, and fsync the containing directory so Btrfs logs the inode in an existence-only mode. If the attacker can then cause or coincide with an unclean shutdown, crash, forced reboot, or power loss, Btrfs log replay may preserve the old file size rather than the zero-byte size. After reboot, affected files may reappear with stale non-zero length, causing corrupted application state, failed cleanup, misleading file contents, or service instability.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the Btrfs fix for incorrect inode size preservation during log replay. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor advisories for the deployed distribution and kernel branch. After updating, reboot into the fixed kernel and ensure the vulnerable kernel is not still active. Where immediate patching is not possible, reduce exposure by limiting local shell access and write access to Btrfs volumes, avoiding use of Btrfs for workloads where crash-consistent file truncation is critical, ensuring reliable power and graceful shutdown procedures, and maintaining tested backups or snapshots. These mitigations reduce likelihood or impact but do not fully correct the kernel flaw.

How to confirm the fix worked

Confirm exposure by identifying systems that run Linux with Btrfs-mounted filesystems, for example by reviewing mount output, /proc/mounts, or configuration management inventory. Confirm remediation by verifying that the running kernel version matches a vendor kernel build that includes the Btrfs inode log-replay fix, not merely that an updated package is installed. Reboot validation is important because kernel fixes are only active after booting the corrected kernel. In non-production test environments, validate with a controlled reproducer or relevant fstests coverage that truncating a file to zero bytes, creating a hard link or rename, fsyncing, and simulating unclean recovery no longer restores the old non-zero size. Also verify that post-reboot filesystem checks, application integrity checks, and backup comparisons do not reveal unexpected file-size reversion on Btrfs volumes.

Typical attack path

1. Obtain local authenticated access to a Linux system using a Btrfs filesystem.
2. Identify a writable directory on the Btrfs-mounted volume.
3. Create or select a file with non-zero size and ensure it is committed or synchronized.
4. Truncate the file to zero bytes and fsync the file.
5. Create a new hard link or perform a rename-related operation that causes Btrfs to log the inode as existing.
6. Fsync the parent directory to force the directory-entry metadata into the Btrfs log.
7. Cause, wait for, or take advantage of an unclean shutdown, crash, or power interruption before normal transaction commit resolves the state.
8. After reboot, rely on Btrfs log replay to restore the file with its prior non-zero size instead of the intended zero size, potentially disrupting software that depends on the truncation.

How to detect it

There is no unique network indicator for this issue because exploitation is local and manifests through Btrfs crash-recovery behavior. To investigate possible prior exploitation or impact, review kernel logs, system journal, and boot history for unclean shutdowns, forced reboots, kernel panics, watchdog resets, or power-loss events on systems using Btrfs. Around those events, look for Btrfs recovery or log-replay messages and then correlate with application errors, unexpected file-size changes, failed state-file parsing, log-rotation anomalies, package-manager errors, or integrity-monitoring alerts after reboot. If auditd, EDR, or shell telemetry is available, search before crash events for suspicious sequences involving file creation or writes, truncate-to-zero operations, fsync-heavy tooling, hard-link creation, rename activity, and directory synchronization in writable Btrfs paths. Forensic review should compare affected files against backups or snapshots to identify files that should have been zero length but retained prior non-zero size. Because the flaw does not produce a reliable attacker-specific artifact, detection should focus on crash timing, Btrfs log replay, local file-operation telemetry, and post-reboot file integrity anomalies.

What your security team should do

• Inventory Linux systems using Btrfs and prioritize those hosting critical application state, log files, package repositories, build artifacts, databases, or shared writable storage.
• Track the relevant distribution or vendor kernel advisory and patch to a kernel that includes the Btrfs log-replay inode-size fix.
• Reboot systems after patching and confirm the fixed kernel is the active running kernel.
• Restrict local interactive access and write permissions on Btrfs-backed filesystems until remediation is complete.
• Review systems that experienced unclean shutdowns while running vulnerable kernels for unexpected file-size reversion or application data inconsistency.
• Ensure backups, snapshots, and restore procedures are current for critical Btrfs volumes.
• Treat this as lower likelihood but potentially high operational impact: EPSS is low and flat, it is not in KEV, and exploitation requires local access plus an unclean shutdown.