Answer in brief
CVE-2026-68442 records a High severity (CVSS 7.8) vulnerability in btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=f86f7a75e2fb5fd7d31d00eab8a392f97ba42ce9 <2a9246a424f45f33a1b8367052611ebe874868ad || >=f86f7a75e2fb5fd7d31d00eab8a392f97ba42ce9 <9304713b70e7e1450e3a76e758836fe5391bfa95 || >=f86f7a75e2fb5fd7d31d00eab8a392f97ba42ce9 <0e465c63f103a5ce6849614d6bda048d70eebec8 || >=f86f7a75e2fb5fd7d31d00eab8a392f97ba42ce9 <5eff4d5b17fa1950e80bfd1ba43dc0699e61a644 | 2a9246a424f45f33a1b8367052611ebe874868ad, 9304713b70e7e1450e3a76e758836fe5391bfa95, 0e465c63f103a5ce6849614d6bda048d70eebec8, 5eff4d5b17fa1950e80bfd1ba43dc0699e61a644 |
| Linux/Linuxgeneric | 6.8 | Not reported |
Published upstream
Aug 12, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 12, 2026
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.
Quoted source text, attributed separately from HOL analysis.