Answer in brief
CVE-2026-68442 records a Unknown severity 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.
A CVSS score is not reported in the current record. 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 12, 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.
Answer in brief
CVE-2026-68442 records a Unknown severity 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.
A CVSS score is not reported in the current record. 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 12, 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.