CVE-2026-98668

What it actually does

The iio_push_to_buffers_with_ts_unaligned() function allocates a bounce buffer via devm_krealloc() without the __GFP_ZERO flag, causing any padding bytes beyond the supplied data length (when not a multiple of 8 bytes) to contain uninitialized heap memory that is then copied to userspace when timestamps are enabled.

Why it matters to the business

User-space processes on affected Linux systems may receive fragments of previously freed or unallocated kernel memory, potentially exposing sensitive information such as cryptographic material, process data, or other kernel internals to local applications.

How an attack unfolds

An attacker with access to an IIO device triggers repeated calls to iio_push_to_buffers_with_ts_unaligned() using data lengths that are not multiples of 8 bytes while timestamps are enabled; the unzeroed padding in the bounce buffer is then read back through the userspace interface, allowing extraction of residual heap contents over multiple invocations.

How to fix it

Upgrade the Linux kernel to a version containing the fix that passes __GFP_ZERO to devm_krealloc() inside iio_push_to_buffers_with_ts_unaligned(); rebuild and deploy the updated kernel across all affected systems.

How to confirm the fix worked

Inspect the kernel source for the presence of __GFP_ZERO in the devm_krealloc() call within iio_push_to_buffers_with_ts_unaligned(); verify the running kernel version is newer than the commit that introduced the change and test that unaligned timestamped buffers no longer contain non-zero padding bytes beyond supplied data.

Typical attack path

1. Obtain local access or compromise a process that can open and interact with IIO character devices.
2. Craft data buffers whose length modulo 8 is nonzero and enable timestamp reporting on the buffer.
3. Invoke the unaligned push path repeatedly to harvest successive allocations of uninitialized memory.
4. Parse returned buffers to locate and exfiltrate useful residual kernel data.

How to detect it

Examine system call logs and audit records for frequent or anomalous opens and writes to IIO device files; correlate with processes that enable timestamps on buffers whose data lengths are not multiples of 8 bytes; review memory dumps or core files from IIO-using processes for unexpected non-zero padding patterns.

What your security team should do

• Prioritize kernel updates on all systems exposing IIO interfaces within the next patch cycle.
• Audit local applications that interact with IIO buffers and restrict unprivileged access to /dev/iio* devices where feasible.
• Monitor upstream stable kernel releases for backported fixes and schedule deployment testing.