CVE-2024-57911

What it actually does

The vulnerability causes uninitialized kernel memory from inactive IIO channels to be copied into a userspace buffer because kmalloc allocates without zeroing and only active channels receive values via iio_for_each_active_channel.

Why it matters to the business

Systems running affected Linux kernels or the listed older Red Hat OpenShift packages risk exposure of kernel memory fragments that may contain sensitive data, raising the chance of further attacks especially on widely deployed kernel versions.

How an attack unfolds

An attacker triggers an IIO dummy buffer read from userspace; the kernel copies the partially initialized data array containing leftover values from inactive channels, allowing direct inspection of uninitialized kernel memory contents. Listed threat actors involved in espionage and financially motivated campaigns have targeted similar Linux kernel uninitialized-resource issues.

How to fix it

Upgrade the Linux kernel to a version containing commit 03fa47621bf8fcbf5994c5716021527853f9af3d or later; for the listed Red Hat OpenShift 3.1 packages apply the exact fixed builds such as 0:3.1.1.6-6.git.43.f583589.el7aos.

How to confirm the fix worked

Confirm the source change from kmalloc to kzalloc in iio_simply_dummy_buffer or verify the running kernel contains the referenced commit hash; test by exercising the triggered buffer with inactive channels and ensuring no uninitialized bytes appear in userspace output.

Typical attack path

1. Locate hosts running vulnerable kernel versions with the IIO dummy module enabled
2. Obtain userspace access sufficient to trigger the buffer and read its output
3. Trigger a buffer event that exercises inactive channels
4. Inspect returned data for patterns indicating uninitialized memory leakage

How to detect it

Search kernel and audit logs for IIO dummy buffer trigger events followed by unusual userspace reads; examine memory dumps or process output for patterns consistent with uninitialized kernel data leakage.

What your security team should do

• Apply the listed fixed kernel commits or package versions immediately on all affected systems
• Disable the IIO dummy module where not required until patches are deployed
• Review systems for the presence of the vulnerable IIO buffer code paths