CVE-2023-53832

What it actually does

Null pointer dereference in md/raid10 during sync/recovery when init_resync sets have_replacement incorrectly after skipped recovery but close_sync is not called, leaving repl_bio unallocated on replacement device paths.

Why it matters to the business

Linux systems using software RAID10 may experience kernel crashes or service disruption during array recovery or device replacement operations, increasing downtime risk on storage servers; low exploitation probability but high impact in enterprise storage environments.

How an attack unfolds

An attacker with local access triggers IO errors on a RAID10 array to mark a device for replacement, adds a replacement device, and forces recovery; the skipped recovery path leaves a null repl_bio that is dereferenced, causing a crash. No named threat actors are associated.

How to fix it

Update the Linux kernel to a version containing commit 38d33593260536840b49fd1dcac9aedfd14a9d42 or later; rebuild and reboot with the patched kernel. Disable unnecessary RAID10 recovery triggers as a temporary mitigation if patching is delayed.

How to confirm the fix worked

Verify the running kernel contains commit 38d33593260536840b49fd1dcac9aedfd14a9d42 via uname or kernel source; test by reproducing the described RAID10 replacement and recovery sequence and confirming no null dereference occurs.

Typical attack path

1. Create or assemble a clean RAID10 array and allow initial resync to complete
2. Trigger conditions that cause recovery to be skipped while still calling init_resync
3. Induce IO errors on a device to set it to WantReplacement
4. Add a new device configured as replacement
5. Wake recovery to trigger dereference of unallocated repl_bio

How to detect it

Search kernel logs and dmesg for null pointer dereference crashes mentioning raid10_sync_request or r10bio; inspect mdadm status and device replacement events around the time of any kernel panics.

What your security team should do

• Prioritize kernel updates on all systems using md RAID10 within standard patch cycles given low EPSS and no KEV listing
• Monitor for kernel oops or panic logs involving raid10_sync_request
• Review RAID array configurations for devices with replacement setups
• Test patched kernels in staging environments that simulate recovery workloads