CVE-2026-68442: Linux Kernel Use-After-Free Vulnerability

CVE-2026-68442 Overview

CVE-2026-68442 is a use-after-free vulnerability in the Linux kernel's btrfs filesystem. The flaw resides in btrfs_drop_extent_map_range(), where splitting an extent map incorrectly propagates the EXTENT_FLAG_LOGGING flag to the newly created split maps. This regression was introduced by commit f86f7a75e2fb ("btrfs: use the flags of an extent map to identify the compression type"), which changed the flag-clearing logic to operate on em->flags instead of the local flags copy used for splits. When the affected extent map is later freed while still linked on the inode's modified_extents list, it triggers a WARN_ON in btrfs_free_extent_map() and leads to a use-after-free condition.

Critical Impact
A use-after-free in the btrfs extent map handling path can lead to kernel memory corruption, denial of service, or potential local privilege escalation on systems using btrfs filesystems.

Affected Products

Linux kernel versions containing commit f86f7a75e2fb ("btrfs: use the flags of an extent map to identify the compression type")
Linux distributions shipping btrfs as a supported filesystem
Systems where btrfs volumes have active extent map logging in progress

Discovery Timeline

2026-08-12 - CVE-2026-68442 published to the National Vulnerability Database (NVD)
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-68442

Vulnerability Analysis

The vulnerability exists in the btrfs (B-tree filesystem) extent map management code within the Linux kernel. When btrfs_drop_extent_map_range() splits an existing extent map, it creates new extent map objects that inherit flags from the original map. The intended behavior is to inherit most flags while explicitly clearing state-specific flags such as EXTENT_FLAG_LOGGING and EXTENT_FLAG_PINNED from the split copies.

A prior refactor changed the clearing logic to operate on the source map's live em->flags field rather than the local flags variable that is used when populating the split maps. As a result, if the original extent map currently has EXTENT_FLAG_LOGGING set, the split maps inherit that flag. The flag is never cleared on the splits, so the extent map remains linked on the inode's modified_extents list.

Root Cause

The root cause is an incorrect variable target in the flag-clearing operation introduced by commit f86f7a75e2fb. Clearing EXTENT_FLAG_LOGGING from em->flags instead of the local flags copy used to seed split maps means the split maps continue to advertise a logging state they never participated in. When these maps are later freed, for example by the extent map shrinker, the WARN_ON(!list_empty(&em->list)) check in btrfs_free_extent_map() fires because the map is still on modified_extents. Freeing an object still referenced by a list produces a use-after-free condition [CWE-416].

Attack Vector

Exploitation requires local access to a system with btrfs volumes and the ability to perform filesystem operations that trigger extent map splitting concurrently with fsync-based logging. Workloads that write to files, then fsync them, and subsequently modify overlapping ranges can produce the split-during-logging scenario. Memory pressure that invokes the extent map shrinker increases the likelihood of triggering the freed-while-listed condition. The vulnerability manifests as a kernel warning followed by memory corruption; consult the referenced kernel git commits for the exact code paths.

Detection Methods for CVE-2026-68442

Indicators of Compromise

Kernel log entries containing WARN_ON warnings originating from btrfs_free_extent_map()
Kernel oops or panic messages referencing btrfs extent map handling functions
Unexpected filesystem errors, remounts to read-only, or process hangs on btrfs mounts under heavy fsync workloads

Detection Strategies

Monitor /var/log/kern.log, dmesg, and journalctl -k output for warnings referencing btrfs_free_extent_map or modified_extents
Correlate kernel warnings with memory pressure events that invoke the extent map shrinker
Track kernel version and patch level across the fleet to identify hosts still running vulnerable btrfs code

Monitoring Recommendations

Enable kernel crash collection via kdump on servers using btrfs to capture forensic evidence of any use-after-free trigger
Aggregate kernel logs from btrfs-backed hosts into a central telemetry pipeline for anomaly detection
Alert on repeated WARN_ON events from btrfs code paths, which may indicate active triggering of this bug

How to Mitigate CVE-2026-68442

Immediate Actions Required

Inventory all Linux hosts running btrfs as a root or data filesystem and record their kernel versions
Apply the upstream stable kernel patches referenced in the git.kernel.org commits as soon as vendor packages are available
Prioritize patching on multi-tenant systems and hosts exposed to untrusted local workloads

Patch Information

The fix restores the pre-regression behavior by clearing EXTENT_FLAG_LOGGING from the local flags copy used for the split maps, while continuing to clear only EXTENT_FLAG_PINNED from em->flags. Fix commits are available in the mainline and stable trees: Kernel commit 0e465c63f103, Kernel commit 2a9246a424f4, Kernel commit 5eff4d5b17fa, and Kernel commit 9304713b70e7.

Workarounds

Reduce memory pressure on affected hosts to lower the probability of the extent map shrinker triggering the freed-while-listed path
Where feasible, migrate high-fsync workloads to non-btrfs filesystems until patches can be deployed
Restrict local shell access on affected systems to trusted users to limit local exploitation opportunities

bash

# Check the running kernel version to determine exposure
uname -r

# Confirm whether btrfs is in use on any mount
mount -t btrfs

# After patching, reboot into the fixed kernel
sudo reboot