CVE-2024-40925

What it actually does

The vulnerability stems from uninitialized queuelist pointers on the first request popped from plug->cached_rq, combined with list_move_tail usage in PREFLUSH/POSTFLUSH state machine paths, leading to list corruption or kernel crash when rq->queuelist.next is dereferenced.

Why it matters to the business

Linux systems may experience unexpected kernel crashes during block I/O flush operations on affected kernels, causing downtime and potential data loss in storage-heavy workloads; the issue affects the stable Linux kernel tree with a fix available in a specific commit.

How an attack unfolds

An attacker with local access crafts I/O patterns that trigger repeated PREFLUSH or POSTFLUSH sequences on block devices, exploiting the uninitialized queuelist to corrupt internal kernel lists and crash the system; no named threat actors are associated with active exploitation of this specific flaw.

How to fix it

Update the Linux kernel to the fixed commit fe1e395563ccb051e9dbd8fa99859f5caaad2e71 in the stable tree; rebuild and deploy the patched kernel across affected systems, ensuring dm layer changes are also considered if using device-mapper.

How to confirm the fix worked

Verify the running kernel contains commit fe1e395563ccb051e9dbd8fa99859f5caaad2e71 by checking git log or kernel version strings; test flush-heavy workloads and monitor for absence of crashes previously triggered by the uninitialized queuelist condition.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel version
2. Issue or trigger block I/O operations that exercise the flush state machine via direct device access or filesystem activity
3. Cause the first request from cached_rq to enter PREFLUSH/POSTFLUSH without queuelist initialization
4. Trigger list_move_tail on the corrupted pointer resulting in kernel panic or memory corruption

How to detect it

Examine kernel logs and dmesg for panic traces referencing blk-flush, queuelist, or list corruption during flush operations; no public indicators of prior exploitation exist given the KEV status.

What your security team should do

• Prioritize kernel upgrades to the fixed commit on production Linux systems handling storage I/O
• Review and test device-mapper configurations for invalid REQ_FSEQ flag combinations
• Monitor kernel crash logs for symptoms matching the queuelist corruption pattern until patches are applied