CVE-2025-38073

What it actually does

Race condition between set_blocksize (which updates i_blksize and minimum folio order) and concurrent read paths that allocate order-0 folios; when block size changes to a larger value, do_mpage_readahead computes blocks_per_folio==0, produces a bio with NULL bdev, and triggers a kernel crash.

Why it matters to the business

Unprivileged local users or automated device-probing processes can trigger kernel panics on Linux systems that use block devices, causing denial of service, unexpected reboots, and potential data corruption or loss of availability for storage-dependent services.

How an attack unfolds

An attacker with local access triggers udev or libblkid to perform a small read on a block device, then quickly initiates a mount of an 8 KB sector-size filesystem on the same device; the resulting race between the read folio and set_blocksize update produces an invalid bio that crashes the kernel.

How to fix it

Upgrade the Linux kernel to a fixed version (6.1.159 or later stable releases containing commit 311427c9384d93ce01f6375a83f93c1c18f7cabe); rebuild and reboot into the patched kernel; for distributions such as Mageia 5 update chrony to 1.31.2-1.mga5 or later.

How to confirm the fix worked

Confirm the running kernel contains the fix commit or reports version 6.1.159+; attempt to reproduce the original race scenario under controlled conditions and verify no crash occurs; inspect dmesg and kernel logs for absence of NULL bdev or folio-order mismatch warnings.

Typical attack path

1. Obtain local shell or trigger device-probing activity (udev/libblkid).
2. Cause a small read that allocates an order-0 folio on the target block device.
3. Concurrently perform a mount or set_blocksize operation for a larger sector size.
4. Trigger the race window that leaves the bio with a NULL bdev.
5. Submit the malformed bio to induce kernel panic.

How to detect it

Search kernel logs and crash dumps for messages indicating NULL block device in bio submission, blocks_per_folio==0, or folio-order mismatches during set_blocksize; correlate with udev-worker or mount activity on the same block device around the time of the panic.

What your security team should do

• Prioritize kernel updates on all systems exposing block devices to untrusted local users.
• Apply the patch or distribution update before the CISA remediation window if the CVE is later added to KEV.
• Restrict local unprivileged access to block devices where feasible until patches are deployed.
• Monitor kernel crash reports and udev activity for anomalous patterns during the update rollout.