CVE-2024-42131

What it actually does

The dirty throttling logic assumes dirty limits in PAGE_SIZE units fit in 32 bits; values exceeding ~16 TB trigger integer overflows, possible division by zero, and related arithmetic errors during limit calculations.

Why it matters to the business

Administrators on systems with very large memory configurations risk kernel instability or crashes if they attempt to set extremely high dirty limits; the issue has low real-world exploit value and no known active campaigns.

How an attack unfolds

A root user invokes the dirty_bytes or dirty_background_bytes sysctl (or equivalent ratio interfaces) with a value larger than UINT_MAX pages; the kernel performs multiplications and divisions that overflow or divide by zero, leading to undefined behavior in the memory management subsystem.

How to fix it

Upgrade the Linux kernel to a version containing commit 2b2d2b8766db028bd827af34075f221ae9e9efff or later; the fix refuses to accept dirty limits that would exceed UINT_MAX pages for both byte and ratio interfaces.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit or is newer than the vulnerable release; attempt to set dirty_bytes above 16 TB and verify the operation is now rejected with an error rather than accepted.

Typical attack path

1. Obtain root privileges on the target system
2. Write a value > 16 TB to /proc/sys/vm/dirty_bytes or /proc/sys/vm/dirty_background_bytes
3. Trigger dirty page throttling (e.g., via heavy write workload)
4. Cause arithmetic overflow or division-by-zero in mm/page-writeback.c logic

How to detect it

Review system logs and audit trails for attempts to set vm.dirty_bytes or vm.dirty_background_bytes to values exceeding 16 TB; no widespread exploitation artifacts are known.

What your security team should do

• Apply the kernel update containing the fix as soon as practical for systems that may expose the sysctl interfaces
• Audit any custom scripts or configuration management that programmatically set dirty_* limits and ensure they stay well below 16 TB
• Monitor vendor or distribution kernel advisories for backported fixes in supported LTS branches