CVE-2024-53076

What it actually does

Memory leak in iio_gts_build_avail_scale_table() where kfree() is not reached for per_time_scales[0] and per_time_gains[0] allocations when a later kcalloc fails inside the loop, because the error label only decrements i down to zero without freeing prior entries.

Why it matters to the business

Repeated triggering of the affected allocation error path in the Linux kernel can gradually exhaust memory, leading to reduced performance, instability, or crashes on systems using the IIO subsystem; low exploitability and no known ransomware use reduce immediate operational urgency.

How an attack unfolds

An attacker with local access triggers the iio_gts_build_avail_scale_table() error path repeatedly by inducing allocation failures (for example via memory pressure) so that earlier per_time_scales and per_time_gains arrays are never freed, accumulating unreclaimed kernel memory until the system becomes unusable.

How to fix it

Update the Linux kernel to the fixed commit 62c11896683129790b8f5ab6eb7e695818b0b723 or later stable releases containing the corrected error handling in iio_gts_build_avail_scale_table().

How to confirm the fix worked

Confirm the running kernel contains commit 62c11896683129790b8f5ab6eb7e695818b0b723; review source for the updated loop that properly frees prior allocations when i >= 0 on error; monitor memory usage during stress tests that exercise the IIO scale table builder.

Typical attack path

1. Obtain local code execution or access on a Linux system using the affected IIO gts-helper code path
2. Force repeated calls to iio_gts_build_avail_scale_table() while creating memory pressure to hit the kcalloc failure branch
3. Observe gradual kernel memory depletion without corresponding frees
4. Continue until system performance degrades or OOM conditions occur

How to detect it

Review kernel logs and memory accounting for repeated allocation patterns around iio_gts_build_avail_scale_table without matching frees; correlate with processes exercising IIO drivers under memory pressure; no public exploitation artifacts are known.

What your security team should do

• Apply the kernel update containing the referenced commit as soon as feasible for affected distributions
• Monitor kernel memory statistics and OOM events on systems exposing IIO devices
• Limit untrusted local access until patches are deployed