The vulnerability in CVE-2026-74376 is a memory leak in Linux MD RAID10's discard path. When processing discards, raid10 reuses r10bio structures that were previously used for read operations. The problem: the read_slot field wasn't reset to -1 during discard preparation. The put_all_bios() function uses read_slot to decide whether to release the repl_bio — since read_slot remained non-negative from the prior read operation, repl_bio never got released, leaking it on every discard operation.
What matters most: the per-event leak is tiny, but RAID10 sits at a storage stack chokepoint. On systems with sustained discard workloads (busy fileservers with SSD-backed RAID10), this leak accumulates over days or weeks. The manifestation isn't a crash — it's gradual OOM pressure, system-wide performance degradation, and page reclaim thrashing that appears unrelated to storage. By the time you notice, the discard operations have long completed.
What to check: verify your kernel is patched (the fix resets read_slot to -1 in the discard preparation path). But also audit your monitoring for slow memory pressure on systems with RAID10 and frequent TRIM/discard — standard crash-focused alerting will miss this.
The deeper concern: this is the same genetic sequence that's appeared in dm-era biosets and block layer plugging. Each time, a new operation type was added to code that reused structures without resetting operation-type-specific fields. The fix here addresses read_slot, but there's likely no explicit enforcement that other fields in r10bio are properly reset when operation types transition. Watch for similar contamination vectors if other operation types are added to the RAID10 reuse path in future kernels.