CVE-2024-42102

What it actually does

Potential multiplication overflow in wb_dirty_limits() dirty throttling calculations on 32-bit architectures when wb_thresh * bg_thresh exceeds 32 bits, leading to incorrect or undefined dirty page limits and possible writeback misbehavior.

Why it matters to the business

Unpatched 32-bit Linux systems may encounter performance degradation, unexpected I/O stalls, or kernel instability under memory pressure or heavy write workloads, increasing operational risk especially for older or embedded deployments.

How an attack unfolds

An attacker with local access crafts sustained high-volume write operations to push dirty thresholds beyond 2^32 pages, triggering arithmetic overflow during throttling calculations and potentially causing kernel instability or denial of service; publicly referenced campaigns involving Linux kernel flaws indicate interest from espionage and financially motivated actors though no public exploits are known for this specific issue.

How to fix it

Upgrade to a fixed kernel version such as 4.19.318 or the mainline commit 253f9ea7e8e53a5176bd80ceb174907b10724c1a; apply the revert of the flawed commit and rebuild if custom kernels are in use.

How to confirm the fix worked

Verify running kernel version against the listed fixed releases; inspect /proc/sys/vm/dirty_* thresholds under load and confirm absence of related writeback warnings in dmesg.

Typical attack path

1. Gain local unprivileged access on 32-bit Linux system
2. Generate continuous high-volume file writes or memory pressure to inflate dirty page counts
3. Trigger wb_dirty_limits() path during writeback balancing
4. Induce arithmetic overflow and observe resulting kernel misbehavior or crash

How to detect it

Review kernel logs for writeback or dirty throttling related warnings, panics, or division errors; correlate with process activity generating sustained writes on 32-bit systems.

What your security team should do

• Apply kernel updates to fixed versions immediately on all 32-bit systems
• Prioritize patching for internet-facing or multi-tenant hosts given 805 days of exposure
• Monitor EPSS and threat actor reports for any rise in observed exploitation
• Test writeback behavior under load after patching to confirm stability