CVE-2026-68442
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk2th percentile - higher than 2% of all known CVEs
Summary
In the Linux kernel's btrfs filesystem, when splitting extent maps, the new maps inherit the EXTENT_FLAG_LOGGING flag, which is never cleared. This can lead to a WARN_ON and use-after-free when the map is freed.
Risk Assessment
The vulnerability can lead to data integrity issues in btrfs, system crashes, or potentially privilege escalation if the UAF is exploited.
Recommendation
Apply the kernel patch that clears EXTENT_FLAG_LOGGING from the local flags copy used for splits, restoring previous behavior.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb ("btrfs: use the flags of an extent map to identify the compression type") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.