CVE-2024-50109

What it actually does

Null pointer dereference in raid10_size() triggered when raid10_run() returns success (zero) after raid10_set_queue_limits() succeeds but later initialization steps fail, leaving mddev->private as NULL.

Why it matters to the business

Kernel crashes or denial of service on Linux systems configured with RAID10 arrays, disrupting storage operations and system availability. Low and stable EPSS suggests limited observed exploitation, though kernel-level impact warrants prompt attention.

How an attack unfolds

An attacker creates conditions that cause raid10_run() to fail after successful queue limit setup, resulting in an erroneous zero return with private still NULL; subsequent access to the array via raid10_size() then dereferences the null pointer, potentially leading to a crash.

How to fix it

Apply the fix from commit b3054db2fd2d35f2eb3b4b5fb1407792f465391c in the Linux kernel stable tree; update to a kernel version containing this commit.

How to confirm the fix worked

Confirm the fix commit is present in the running kernel source tree and verify that raid10_run() properly propagates errors without overwriting the return value on success paths.

Typical attack path

1. Trigger or manipulate md RAID10 array initialization to reach the error path after raid10_set_queue_limits()
2. Allow raid10_run() to return success despite mddev->private remaining NULL
3. Invoke raid10_size() or equivalent array sizing operation to trigger the dereference

How to detect it

Search kernel logs and crash dumps for references to raid10_size, raid10_run, or null pointer dereferences involving md private structures during array initialization.

• raid10_size
• raid10_run
• mddev->private

What your security team should do

• Prioritize kernel updates containing b3054db2fd2d35f2eb3b4b5fb1407792f465391c on all systems using md RAID10
• Review RAID configurations and test array activation after patching
• Monitor kernel logs for related null pointer dereference events during storage setup