HIGH Introduced in 6.8
btrfs ExtentMap UAF
CVE-2026-68442
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
01Description
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.
02KernelScan AI Analysis
Risk summary
A use-after-free in the btrfs extent map handling can be triggered by any local user performing file operations on a mounted btrfs filesystem. The bug requires a race between extent map splitting and transaction logging, making reliable exploitation difficult but potentially granting kernel-level code execution or causing a system crash.
Vulnerability analysis
When the btrfs filesystem driver splits a memory structure that tracks file extents, the new pieces inherit flags from the original. A prior change caused the logging flag to be cleared only on the original structure but not on the copy used to create the new pieces, so the splits wrongly keep the logging flag and are never properly removed from the file's tracking list. When the memory reclaim thread later frees such a split, it is still linked on that list, triggering a warning and a use-after-free. The fix restores the original behaviour by clearing the logging flag from the copy used for the splits while preserving it on the original structure. Any local user with write access to files on a mounted btrfs filesystem can trigger this through ordinary file operations, though exploitation requires winning a race between concurrent logging and splitting.
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.12 | 6.8 | 6.12.101 | 2a9246a424f4 |
| 6.18 | 6.8 | 6.18.42 | 9304713b70e7 |
| 7.1 | 6.8 | 7.1.6 | 0e465c63f103 |
| mainline | 6.8 | 7.2-rc5 | 5eff4d5b17fa |