CVE-2024-43820

What it actually does

Incorrect check in dm-raid raid_resume assumes MD_RECOVERY_RUNNING implies a registered sync_thread, but md_check_recovery can set the flag independently, producing spurious WARN_ON_ONCE.

Why it matters to the business

Kernel warnings appear during resume of dm-raid devices after table loads, increasing log noise and complicating stability monitoring in Linux environments.

How an attack unfolds

No known remote exploitation path exists; the issue surfaces only when a dm-raid device is suspended, its table reloaded, and then resumed under conditions that set the recovery flag without thread registration.

How to fix it

Apply the upstream fix present in commit e8f897f4afef0031fe618a8e94127a0934896aba or later; rebuild and deploy the updated kernel across affected systems.

How to confirm the fix worked

Confirm the commit e8f897f4afef0031fe618a8e94127a0934896aba is present in the running kernel source tree; exercise dm-raid suspend/resume cycles and verify absence of the warning.

Typical attack path

1. Create or reload a dm-raid device table
2. Suspend the device
3. Resume the device
4. md_check_recovery sets MD_RECOVERY_RUNNING without registering sync_thread
5. raid_resume hits the incorrect WARN_ON_ONCE

How to detect it

Search kernel logs and dmesg for the raid_resume warning; correlate with dm-raid table load and resume events in audit or system logs.

• WARNING: CPU: .* PID: .* at drivers/md/dm-raid.c:4105 raid_resume+0xee/0x100 [dm_raid]
• test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)

What your security team should do

• Prioritize kernel update on systems using dm-raid
• Add the WARN_ON_ONCE string to log monitoring rules until patches are deployed
• Review RAID device resume automation for unnecessary suspend/resume cycles