CVE-2024-35979

What it actually does

The vulnerability is a use-after-free in raid1_write_request() where r1_bio->bios[] is temporarily set to the original bio before per-device bios are allocated; encountering a Blocked rdev triggers free_r1bio()/put_all_bios() which calls bio_put() on the original bio, freeing it while it may still be referenced.

Why it matters to the business

Linux systems using software RAID1 arrays with direct I/O workloads may experience kernel panics or memory corruption under specific device-blocking conditions, causing service outages, data access loss, and unplanned downtime until the kernel is updated.

How an attack unfolds

An attacker with local access performs direct I/O writes against an md RAID1 device while simultaneously placing one underlying rdev into the Blocked state; this exercises the faulty bio assignment path, frees the original bio prematurely, and can lead to reuse-after-free memory corruption.

How to fix it

Update the Linux kernel to a version containing commit 3f28d49a328fe20926995d5fbdc92da665596268 (or the equivalent stable backport) in drivers/md/raid1.c; rebuild and reboot with the fixed kernel. Where immediate patching is not possible, avoid direct I/O workloads on RAID1 arrays or temporarily disable affected arrays.

How to confirm the fix worked

Confirm the running kernel contains commit 3f28d49a328fe20926995d5fbdc92da665596268; review raid1.c for the mempool_free() change in the blocked-rdev handling path; re-run the provided fio + blocked-state test and verify absence of bio-use-after-free BUG messages.

Typical attack path

1. Obtain local code execution on a system with an md RAID1 array
2. Issue direct I/O write requests to the md device (e.g., via libaio)
3. Set one array member rdev to the Blocked state via sysfs
4. Trigger raid1_write_request() path that hits the blocked-rdev branch
5. Observe resulting use-after-free during bio_put()

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for BUG messages referencing bio-*, mempool_free_slab, or free_r1bio during md/raid1 activity; correlate with processes performing direct I/O (blkdev_direct_IO, aio_write) against md devices while devices enter Blocked state.

What your security team should do

• Prioritize kernel updates on all systems exposing md RAID1 with direct I/O
• Monitor kernel logs for bio-related BUG/Use-after-free reports on md devices
• Restrict unprivileged direct I/O access to block devices until patches are applied
• Test the fixed kernel in staging environments before broad deployment