CVE-2024-57906

What it actually does

The driver fails to zero-initialize a local buffer before copying channel data to userspace, leaving values for inactive channels as uninitialized kernel memory.

Why it matters to the business

Attackers with access to the device may obtain fragments of unrelated kernel memory, increasing the chance of credential or address disclosure on systems using this ADC.

How an attack unfolds

An attacker with local access enables the triggered buffer on the ti-ads8688 device, requests a capture that includes only a subset of channels, then reads the returned buffer to extract residual kernel data that was never cleared.

How to fix it

Update the Linux kernel to a version containing commit 62fb9874f5da54fdb243003b386128037319b219 or later; rebuild and deploy the updated kernel image on affected systems.

How to confirm the fix worked

Confirm the running kernel contains commit 62fb9874f5da54fdb243003b386128037319b219, then exercise the triggered buffer path while monitoring for zeroed inactive channel values in captured data.

Typical attack path

1. Obtain local unprivileged access on a Linux system exposing the ti-ads8688 IIO device
2. Configure a triggered buffer using only a subset of channels via sysfs or libiio
3. Trigger a data capture and read the resulting buffer from userspace
4. Scan the returned data for non-zero residual bytes that were never written by the driver

How to detect it

Review kernel audit logs and IIO device access records for unexpected buffer reads on ti-ads8688; inspect captured sample buffers for non-zero values in channels that were not enabled during the capture.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all systems exposing the ti-ads8688 driver
• Restrict unprivileged access to IIO character devices until patches are applied
• Monitor kernel update channels for backports to supported LTS branches