CVE-2024-49994

What it actually does

Integer overflow in BLKSECDISCARD ioctl handling allows crafted 64-bit range values to trigger near-infinite looping inside blkdev_issue_secure_erase with repeated bio submissions that exceed device limits.

Why it matters to the business

Systems processing untrusted discard or secure-erase requests can experience sustained high CPU usage, I/O storms, and device unavailability, increasing operational risk for storage-dependent workloads; widespread kernel exposure across distributions amplifies the need for prompt patching.

How an attack unfolds

An attacker with local access to a block device issues a BLKSECDISCARD ioctl containing an overflow-prone start/length pair; the kernel enters blkdev_issue_secure_erase, repeatedly generates out-of-bounds bios, logs repeated access-beyond-end messages, and loops until the process is killed or the system is rebooted.

How to fix it

Update the Linux kernel to a version containing commit 8476f8428e8b48fd7a0e4258fa2a96a8f4468239 or later; for Rocky Linux 8 deployments apply the listed fixed packages for mod_md (1:2.0.8-8.module+el8.5.0+695+1fa8055e), httpd (0:2.4.37-39.module+el8.4.0+571+fd70afb1), and mod_http2 (0:1.15.7-3.module+el8.4.0+553+7a69454b).

How to confirm the fix worked

Confirm the running kernel contains the referenced commit hash; attempt the original ioctl reproducer and verify it returns an immediate error instead of entering the loop; monitor kernel logs for absence of repeated bio_check_eod suppression messages during discard operations.

Typical attack path

1. Obtain local unprivileged or container access to a system exposing block devices
2. Open a target block device or loop device file descriptor
3. Craft a two-element uint64_t array with values that overflow when added to the device size
4. Invoke ioctl(fd, BLKSECDISCARD, array) to trigger the vulnerable path
5. Observe sustained kernel looping and device I/O errors

How to detect it

Search kernel logs for repeated 'bio_check_eod' suppression messages combined with 'attempt to access beyond end of device' entries; correlate with processes issuing BLKSECDISCARD ioctls via audit or strace artifacts.

What your security team should do

• Prioritize kernel updates on all systems exposing block devices to untrusted users or containers
• Restrict BLKSECDISCARD and related ioctls via LSM or seccomp filters where device access cannot be removed
• Audit local code and scripts that issue secure-erase or discard ioctls for safe range validation
• Monitor EPSS and KEV updates for any future elevation in exploitability