CVE-2025-38709

What it actually does

Race condition in the Linux kernel loop device driver allows block size updates on a device that is exclusively owned by a mounted filesystem, leading to mismatch between device block size and filesystem superblock expectations and subsequent failures in buffer cache operations.

Why it matters to the business

Systems running affected kernel versions may experience unexpected warnings, filesystem instability, or denial of service when loop devices are reconfigured concurrently with active mounts; widespread in Linux distributions and container environments increases operational risk and patch urgency.

How an attack unfolds

An attacker with local access creates or attaches a loop device, mounts a filesystem on it, then races to change the block size while the filesystem holds exclusive ownership, triggering the mismatch that the original fix prevents by enforcing exclusive ownership checks.

How to fix it

Update the Linux kernel to a version containing commit 457d2c5e112fd08dc1039b1ae39a83ec1782360d or later; rebuild and reboot with the patched kernel; avoid manual block-size changes on active loop devices.

How to confirm the fix worked

Verify the running kernel contains commit 457d2c5e112fd08dc1039b1ae39a83ec1782360d via git describe or kernel version string; attempt the original syzbot reproducer and confirm it no longer produces the __getblk_slow warning.

Typical attack path

1. Obtain local unprivileged or low-privileged access on a Linux system
2. Create and configure a loop device with an initial block size
3. Mount a filesystem on the loop device to acquire exclusive ownership
4. Race a block-size change operation against the mounted device
5. Trigger buffer cache operations that expose the size mismatch

How to detect it

Review kernel logs for __getblk_slow warnings mentioning block size mismatches on loop devices; correlate with process activity that manipulates loop-control or losetup while filesystems are mounted; examine audit logs for loop ioctl calls concurrent with mount operations.

What your security team should do

• Prioritize kernel updates on all systems using loop devices or containers within the next maintenance window
• Audit custom scripts or tools that alter loop device parameters while filesystems are mounted
• Monitor kernel changelogs for related loop or block-layer fixes
• Consider restricting unprivileged loop device creation via kernel parameters or SELinux/AppArmor policies