CVE-2021-47066

What it actually does

Incorrect handling of src_offs array when parity page is reused as source in RMW mode for async_xor operations causes the computed XOR value to be wrong, resulting in invalid parity and subsequent data corruption on RAID5 arrays.

Why it matters to the business

Systems using certain RAID5 configurations may experience silent data corruption, filesystem errors, or mount failures, leading to unplanned downtime, data recovery efforts, and potential loss of recent writes.

How an attack unfolds

An attacker with local access or the ability to trigger RAID5 RMW operations (such as by writing to a mounted array with the vulnerable kernel) can force the async_xor path to reuse the parity page without updating offsets, corrupting stripe data.

How to fix it

Update the Linux kernel to a version containing the async_xor src_offs fix; rebuild and reboot onto the patched kernel; verify RAID arrays for consistency after upgrade.

How to confirm the fix worked

Confirm kernel version contains commit fixing async_xor offset handling; run RAID consistency checks (mdadm --check) and filesystem verification tools; attempt reproduction steps from the advisory on test hardware.

Typical attack path

1. Configure or access a Linux MD RAID5 array with stripe size != PAGE_SIZE
2. Perform writes that trigger RMW parity updates via ops_run_prexor5
3. Trigger async_xor with ASYNC_TX_XOR_DROP_DST set using parity as source
4. Observe incorrect XOR result leading to corrupted blocks on disk

How to detect it

Search kernel logs and dmesg for RAID5 or async_xor related errors, XFS or ext4 corruption messages, and unexpected mount failures; correlate with systems running vulnerable kernel versions and RAID5 arrays.

What your security team should do

• Prioritize kernel updates on systems using MD RAID5
• Monitor for filesystem errors or mount failures on RAID volumes
• Test RAID workloads on patched kernels before broad deployment
• Review backup and recovery procedures for RAID-hosted data