CVE-2026-43118: Linux Kernel Privilege Escalation Flaw

CVE-2026-43118 Overview

CVE-2026-43118 is a Linux kernel vulnerability in the btrfs filesystem. The flaw causes inode size inconsistency after log replay, where a file truncated to zero retains its previous non-zero size following a power failure or crash. The issue lives in the btrfs log tree code path, specifically in fill_inode_item() and overwrite_item(), which incorrectly handle the inode generation field when an inode is logged in LOG_INODE_EXISTS mode after a prior full log.

Critical Impact
After a crash or power failure, files truncated to zero may incorrectly retain their previous size on disk, leading to filesystem state inconsistency and potential data integrity issues.

Affected Products

Linux kernel (btrfs filesystem subsystem)
Distributions shipping affected mainline and stable kernel branches
Systems using btrfs as the root or data filesystem

Discovery Timeline

2026-05-06 - CVE-2026-43118 published to NVD
2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43118

Vulnerability Analysis

The vulnerability resides in the btrfs log replay logic. When btrfs logs that an inode exists as part of recording a new name or new directory entries, it sets the generation of the logged inode item to 0. This sentinel value signals overwrite_item() during log replay to preserve the existing i_size from the subvolume tree, since logging an inode existence does not include extent data.

The logic breaks when an inode has already been logged in full mode within the same transaction, or when an inode created in a prior transaction is logged for the first time with a new i_size of 0. If a new name is then logged due to a hard link or rename, btrfs records an i_size of 0 together with a generation of 0. During replay, overwrite_item() interprets the zero generation as a directive to skip the size update, leaving stale size metadata in the inode.

Root Cause

The root cause is the conflation of two distinct conditions in fill_inode_item(). The function uses generation 0 both as a marker for existence-only logging and inadvertently for inodes that were previously logged with real size data in the current transaction. The patched code now logs the real generation of the inode when it was logged in the current transaction with a recorded i_size, and uses the i_size from the commit root for inodes from prior transactions logged in exists-only mode.

Attack Vector

The issue is a local data integrity flaw rather than a remote attack vector. Triggering the inconsistency requires filesystem operations: creating a file, writing data, truncating, syncing, then creating a hard link or rename, followed by an fsync on the directory and an unclean shutdown. The reproducer uses xfs_io with pwrite, truncate, fsync, and ln, followed by a power fail, after which the file retains its pre-truncate 64K size instead of the expected zero size.

No verified exploit code is available. The vulnerability is described in prose by the upstream kernel developers and corrected in the referenced Git commits. See the Linux kernel commit fddb157536e6 for the canonical fix.

Detection Methods for CVE-2026-43118

Indicators of Compromise

Files on btrfs volumes showing non-zero i_size after a recorded truncate to 0 followed by an unclean shutdown.
Discrepancies between expected file content length and stat() reported size after log replay.
Filesystem consistency check failures reported by btrfs check referencing inode size mismatches.

Detection Strategies

Audit kernel versions across the fleet against the patched commits referenced in the kernel git tree.
Monitor dmesg and journal output for btrfs log replay messages following abnormal shutdowns.
Run scheduled btrfs scrub and btrfs check --readonly operations on production volumes to surface size and metadata anomalies.

Monitoring Recommendations

Track kernel package versions through configuration management to confirm patched builds are deployed.
Alert on unexpected reboots and power-loss events on btrfs hosts and trigger post-recovery filesystem audits.
Collect application-level checksums or sizes for critical data files to detect post-replay divergence.

How to Mitigate CVE-2026-43118

Immediate Actions Required

Update affected systems to a Linux kernel build that includes the upstream btrfs fix referenced in the kernel git commits.
Identify hosts using btrfs for root or data volumes and prioritize them for kernel updates.
Ensure backups of critical btrfs-hosted data are current before applying kernel updates and rebooting.

Patch Information

The fix is delivered in the upstream Linux kernel via the following commits: 03e966b63df5, 5254d4181add, and fddb157536e6. The patch modifies fill_inode_item() to log the real inode generation when it was logged in the current transaction with a recorded i_size, and to source i_size from the commit root for exists-mode logging of older inodes.

Workarounds

Where kernel updates cannot be applied immediately, ensure systems are protected by uninterruptible power supplies to reduce the chance of triggering log replay scenarios.
Avoid workload patterns that combine truncation, fsync, and hard link or rename operations on the same files where feasible.
Maintain frequent application-level snapshots or backups so that any post-replay inconsistency can be detected and rolled back.

bash

# Verify running kernel version and btrfs filesystem usage
uname -r
findmnt -t btrfs

# After patching, reboot and confirm the new kernel is active
sudo reboot
uname -r