The vulnerability lives in the RAID1 and RAID10 error handlers within the Linux MD subsystem. When a bio is split or resubmitted during recovery operations, the error detection code attempts to access r1_bio or r10_bio->read_slot directly — fields that become invalid or dangling after the bio is cloned. The correct approach is to use md_cloned_bio() to check bio state, which abstracts away the lifecycle complexity introduced by splitting operations.
The trigger condition is specific and insidious: memory pressure causing GFP flags to downgrade, combined with a RAID array attempting recovery. Under these conditions, the direct field access doesn't produce a compile-time error or obvious crash — it produces deadlock. The system hangs while trying to recover from the original I/O error, effectively turning the recovery machinery into a failure amplifier. This is why the CVSS 7.5 likely understates the real risk: deadlock during recovery can cascade into data unavailability far worse than the initial read/write failure.
The fix is straightforward — replace direct field access with md_cloned_bio() in the error paths. However, you should audit the broader MD codebase. RAID5, RAID6, and dm-raid handlers may have similar patterns where direct bio field access coexists with the helper abstraction. The deeper question is whether your kernel version's bio lifecycle refactoring introduced new semantics that some call sites haven't migrated to handle. Check md_cloned_bio() usage across all RAID personalities, not just the ones explicitly patched, and verify that any direct bio field access in error paths is either using the helper or is demonstrably safe under split/resubmit conditions.