CVE-2024-49933

What it actually does

Undefined behavior from excessively large shift exponents in the ioc_forgive_debts function of the block I/O cost accounting subsystem, allowing shift-out-of-bounds operations on u64 values that UBSAN detects as invalid.

Why it matters to the business

Potential for kernel instability, crashes, or unpredictable I/O scheduling behavior on Linux systems, raising risk of operational disruptions in environments relying on blk-iocost, though no confirmed real-world exploitation impact.

How an attack unfolds

An attacker triggers the ioc_timer_fn path under conditions that cause debt calculations in ioc_forgive_debts to compute excessively large exponents, leading to the out-of-bounds shift; the issue stems from missing bounds checks before shift operations and is primarily a correctness problem rather than a proven remote code execution vector.

How to fix it

Update the Linux kernel to a version containing commit 1f61d509257d6a05763d05bf37943b35306522b1, which precalculates the shift exponent using a minimum of the actual value and the maximum valid bits for the type.

How to confirm the fix worked

Confirm the presence of the fix commit in the running kernel source or binary, then recompile and test with UBSAN enabled to verify absence of shift-out-of-bounds reports in ioc_forgive_debts.

Typical attack path

1. Activate blk-iocost on a block device via cgroup configuration
2. Generate I/O workloads that accumulate debts triggering forgiveness logic
3. Force calculation of shift exponents exceeding 63 bits
4. Observe resulting undefined behavior in kernel timer context

How to detect it

Inspect kernel logs for UBSAN warnings referencing shift-out-of-bounds in block/blk-iocost.c around lines 2142 and 2144, particularly in ioc_timer_fn call traces.

• UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38
• shift exponent 80 is too large for 64-bit type 'u64'
• UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30
• ioc_timer_fn+0x6cec/0x7750

What your security team should do

• Prioritize kernel updates on systems using blk-iocost for I/O control
• Enable UBSAN or similar sanitizers in test environments to catch similar issues
• Review I/O cgroup configurations for unnecessary exposure to iocost
• Monitor upstream stable kernel releases for related fixes