CVE-2024-45023

What it actually does

read_balance() in md/raid1 can return a normal but still-unrecovered disk when choose_bb_rdev or choose_slow_rdev omit recovery-state checks, causing reads of uninitialized data in degraded arrays that contain only slow disks.

Why it matters to the business

Silent data corruption can occur on RAID1 volumes during recovery or when slow disks are present, risking loss of integrity for stored data, application failures, and extended downtime for recovery or rebuilds; low urgency given minimal exploitability signals and no ransomware or KEV usage.

How an attack unfolds

An attacker with local access manipulates or waits for a degraded RAID1 state containing only slow disks while a replacement disk is still recovering, then triggers reads that the faulty choose_bb_rdev/choose_slow_rdev path satisfies from the unrecovered device, returning invalid data.

How to fix it

Upgrade the Linux kernel to a version containing commit 2febf5fdbf5d9a52ddc3e986971c8609b1582d67 or later; for github.com/KubeOperator/kubepi update to 1.6.3 or newer; rebuild and reboot affected systems; test RAID recovery paths after patching.

How to confirm the fix worked

Confirm the running kernel contains the recovery check added to choose_bb_rdev and choose_slow_rdev; exercise degraded-array read workloads with slow disks and verify no unrecovered data is served; inspect dmesg for raid1 recovery messages.

Typical attack path

1. gain local execution or storage configuration rights
2. induce or observe a degraded RAID1 array whose only valid members are slow disks
3. ensure a replacement disk is still in recovery
4. issue reads that reach raid1_read_request and read_balance
5. receive unrecovered data leading to corruption

How to detect it

Review kernel logs for raid1_read_request and read_balance entries around the time of suspected corruption; correlate with mdstat showing degraded arrays and slow disks; inspect application-level checksum or integrity failures on RAID-backed storage.

What your security team should do

• Apply the referenced kernel commit or distribution update within normal change windows
• Inventory systems using md/raid1 and schedule staged rollouts
• Add RAID array health and slow-disk alerts to existing monitoring
• Re-test backup/restore procedures that rely on RAID volumes