CVE-2024-47725

What it actually does

dm-verity fails to invoke panic or restart on I/O errors when panic_on_corruption or restart_on_corruption modes are configured, allowing EIO conditions from sectors created via Write Uncorrectable commands to propagate to user-space programs instead of halting the system.

Why it matters to the business

Systems relying on dm-verity integrity protection may experience unexpected application failures or continued operation with corrupted data, increasing operational risk on Debian Linux deployments until upgraded; the issue has been public for over 700 days with no known active exploitation campaigns.

How an attack unfolds

An attacker with the ability to issue SCSI Write Uncorrectable commands targets dm-verity protected devices to manufacture persistent I/O error sectors. When a verification read hits these sectors, the kernel returns EIO rather than triggering the configured panic or restart, allowing dependent programs to receive errors and potentially misbehave or leak state without system termination.

How to fix it

Upgrade the linux package on Debian 13 to version 6.11.2-1 or later. After upgrade, ensure dm-verity targets continue to be configured with panic_on_corruption or restart_on_corruption as appropriate for the environment. Reboot to load the fixed kernel.

How to confirm the fix worked

Confirm the running kernel is at least 6.11.2-1 via uname -r, verify dm-verity targets still specify the desired corruption handling mode in /etc/crypttab or dmsetup output, and test that an injected I/O error on a verity device now produces the expected panic or restart behavior.

Typical attack path

1. Identify dm-verity protected block devices on the target system
2. Use Write Uncorrectable or equivalent low-level commands to create error-returning sectors
3. Trigger reads that cause dm-verity to encounter the error sectors
4. Observe EIO returned to user-space applications instead of system panic or restart

How to detect it

Search kernel logs for dm-verity I/O error messages that are not immediately followed by a panic or reboot. Review auditd or syslog entries around EIO returns from verity devices and correlate with any application-level error handling anomalies. No public exploitation artifacts are known.

What your security team should do

• Prioritize patching Debian 13 systems running dm-verity to linux 6.11.2-1 within standard change windows
• Audit existing dm-verity configurations to confirm corruption handling modes are set according to policy
• Update vulnerability scanning and patch management tools to flag any remaining pre-6.11.2-1 linux packages on Debian 13