CVE-2025-38444

What it actually does

Memory leak in raid10_make_request when raid10_read_request or raid10_write_request allocates from mempool under REQ_NOWAIT flag without subsequent free on the error path.

Why it matters to the business

Gradual memory exhaustion on systems using Linux software RAID10 under asynchronous or direct I/O workloads can cause performance degradation, application failures, or kernel instability requiring reboots; high downstream package prevalence increases exposure across server and container fleets.

How an attack unfolds

An attacker with local access or the ability to submit I/O requests (including via containers) repeatedly triggers raid10 request paths with the NOWAIT flag set, causing unreleased mempool allocations that accumulate until memory pressure leads to denial of service; listed threat actors have exploited similar Linux kernel memory issues for privilege escalation in container-optimized environments.

How to fix it

Upgrade to fixed kernel versions: 5.15.189, 6.12.41-1, 6.16.3-1, or apply commit 10c6021a609deb95f23f0cc2f89aa9d4bffb14c7 from the stable git tree; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm kernel version matches or exceeds listed fixed releases; monitor /proc/meminfo or slabinfo for sustained growth in raid10-related objects under load; run regression tests exercising direct I/O on raid10 arrays.

Typical attack path

1. Identify or deploy workload capable of issuing direct or async I/O against a raid10 device
2. Submit repeated requests with REQ_NOWAIT flag to exercise raid10_make_request allocation path
3. Trigger error conditions after allocation so the mempool object is not freed
4. Repeat to exhaust available memory and induce system instability or OOM conditions

How to detect it

Review kernel logs for raid10 allocation backtraces matching the provided stack; correlate with process activity performing direct I/O (io_uring, blkdev_read_iter); watch for increasing unreferenced mempool objects in slab caches under fio or similar workloads.

• raid10_make_request+0x19e/0x650
• unreferenced object.*size 192.*comm "fio"
• __kmalloc.*mempool_alloc.*raid10_make_request

What your security team should do

• Prioritize patching systems with raid10 configurations and high I/O throughput within the next maintenance window
• Inventory all Linux kernel versions across fleet and map against the per-distribution fixed packages provided
• Enable memory accounting and OOM logging to detect abnormal slab growth
• Restrict untrusted local access and container workloads until patches are deployed