CVE-2026-68442

This CVE exposes a fundamental coupling problem in BTRFS extent map lifecycle management, and the bug itself is almost secondary to what it reveals about how state propagates across subsystem boundaries. The vulnerability stems from commit f86f7a75e2fb, which changed how extent map flags are accessed during compression type identification — shifting from a local copy to directly reading em->flags. That change had an unintended side effect: EXTENT_FLAG_LOGGING, a transient marker indicating an extent map is in a logged context, now gets carried through extent map splits when it shouldn't. The flag was designed to block freeing while in a logging context, but it's being inherited through split operations as if it were persistent metadata. The use-after-free only triggers when three conditions align: an extent map is being logged, it gets split during drop operations, and the shrinker frees the split map while it's still on the modified_extents list. The WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() is the only thing catching this — it surfaces the inconsistency between the flag state (indicating the map is logged and shouldn't be freed) and the list state (showing it's still on a shared list awaiting cleanup). Strip that assertion and you have silent memory corruption. The patch restores clearing on a local flags copy, which fixes the immediate crash. But this is a surgical fix on a structural wound. The real problem is that EXTENT_FLAG_LOGGING is both a transient context marker and an inherited flag — these are contradictory semantics that the current flag model allows. Extent map splitting copies the entire flag set rather than filtering for structural flags only. The shrinker assumes list membership and flag state are consistent, but transient flags can violate that invariant silently. What you should do: apply the patch immediately, as the UAF is exploitable with any workload that triggers logged extent map splits under memory pressure. But treat this as a warning sign, not a one-off fix. Audit other EXTENT_FLAG_* variables for the same pattern — transient markers that might be inherited through split, clone, or copy operations. Consider adding a lint check that flags unmarked flag propagation through these operations. The next similar bug may not have a WARN_ON saving it.

Reviewed through automated stages and approved by a human before publication.