CVE-2024-42102 in Linux
Summary
by MITRE • 07/30/2024
In the Linux kernel, the following vulnerability has been resolved:
Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
Patch series "mm: Avoid possible overflows in dirty throttling".
Dirty throttling logic assumes dirty limits in page units fit into 32-bits. This patch series makes sure this is true (see patch 2/2 for more details).
This patch (of 2):
This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.
The commit is broken in several ways. Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the default settings with 4GB of RAM will trigger this). Secondly, the div64_u64() is unnecessarily expensive on 32-bit archs. We have div64_ul() in case we want to be safe & cheap. Thirdly, if dirty thresholds are larger than 1<<32 pages, then dirty balancing is going to blow up in many other spectacular ways anyway so trying to fix one possible overflow is just moot.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/19/2025
The vulnerability CVE-2024-42102 represents a critical issue within the Linux kernel's memory management subsystem, specifically affecting the dirty throttling mechanism that controls writeback operations. This flaw manifests in the wb_dirty_limits() function where the kernel's dirty page tracking logic fails to properly handle arithmetic operations that could lead to division by zero or integer overflow conditions. The vulnerability stems from an attempted fix that was subsequently reverted due to its own inherent design flaws and compatibility issues across different hardware architectures. The problematic commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78 introduced a u64 cast removal from multiplication operations that, while seemingly addressing a potential divide-by-zero scenario, created new and more severe issues on 32-bit systems where arithmetic overflow conditions became prevalent. This issue directly impacts the kernel's memory management stability and can lead to system crashes or unpredictable behavior during heavy I/O operations when the dirty page limits exceed certain thresholds.
The technical implementation of this vulnerability lies in the kernel's dirty throttling algorithm which assumes that dirty limits expressed in page units will fit within 32-bit integer boundaries. When the wb_thresh * bg_thresh multiplication exceeds 2^32, the removal of the u64 cast causes overflow conditions that result in incorrect calculations and potential system instability. The mathematical operation involves dividing large 64-bit values using div64_u64() function, which is computationally expensive on 32-bit architectures where simpler div64_ul() operations would suffice. The patch series was designed to address integer overflow conditions but inadvertently introduced a regression that affects systems with default memory configurations, particularly those with 4GB RAM where the default dirty threshold settings trigger the overflow condition. This vulnerability aligns with CWE-191, which describes integer underflow or overflow conditions, and specifically demonstrates the risks associated with improper arithmetic overflow handling in kernel space operations.
The operational impact of CVE-2024-42102 extends beyond simple system instability to potentially compromise data integrity and system availability during sustained write operations. Systems running on 32-bit architectures face the highest risk as the overflow conditions are more likely to occur with default configuration parameters. The dirty throttling mechanism controls how quickly dirty pages are flushed from memory to storage, and when this mechanism fails, it can lead to excessive memory pressure, writeback starvation, or complete system lockups. Attackers could potentially exploit this vulnerability by triggering specific I/O patterns that force the kernel into the problematic code path, though the direct exploitation risk is relatively low compared to other kernel vulnerabilities. The vulnerability affects all Linux kernel versions that include the problematic commit and impacts systems with default memory configurations where dirty thresholds approach or exceed 2^32 page boundaries. This issue particularly affects server environments and systems handling large volumes of I/O operations, where the dirty page tracking mechanism is heavily utilized.
Mitigation strategies for CVE-2024-42102 focus on applying the appropriate kernel patches that revert the problematic commit and restore proper overflow handling mechanisms. System administrators should prioritize updating their kernel installations to versions that include the corrected implementation of the dirty throttling logic, which properly handles 64-bit arithmetic operations and maintains compatibility across both 32-bit and 64-bit architectures. The fix ensures that dirty limits are properly constrained to prevent overflow conditions while maintaining efficient computation on all supported platforms. Organizations should monitor their systems for signs of memory pressure or I/O performance degradation that might indicate the vulnerability is active, particularly on 32-bit systems or those with large memory configurations. Additionally, implementing proper kernel hardening measures and monitoring for unusual memory management patterns can help detect potential exploitation attempts. The solution addresses the underlying issue by maintaining appropriate type casting and arithmetic boundaries that prevent both overflow conditions and unnecessary computational overhead on resource-constrained systems. This vulnerability demonstrates the complexity of kernel-level arithmetic operations and the importance of thorough testing across different hardware platforms when implementing memory management fixes.