CVE-2026-31768

What it actually does

This is a local Linux kernel memory-corruption issue in the ti-adc161s626 Industrial I/O ADC driver. The driver used stack memory as the receive buffer for spi_read(), but SPI transfer buffers must be DMA-safe. On systems where the SPI controller uses DMA, this can result in invalid DMA access, kernel stack corruption, memory disclosure, or a kernel crash when ADC reads are triggered. Because exploitation occurs in kernel context, successful abuse can potentially affect confidentiality, integrity, and availability of the host.

Why it matters to the business

Systems that include and use the affected Linux kernel driver may be exposed to local privilege escalation or denial of service. The practical exposure is likely limited to Linux devices with the TI ADC161S626 ADC driver present and accessible to local users, and the currently observed exploitation likelihood is low: EPSS is approximately 0.0013, stable over 30 days, with no known KEV listing, ransomware association, or public exploit maturity reported. Embedded, industrial, IoT, and hardware-integrated Linux deployments should still treat this seriously because kernel compromise can lead to full device takeover or operational disruption.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system and enough permissions to trigger reads from the affected ADC device through the Industrial I/O interface, such as sysfs, device nodes, or an application path that exposes ADC sampling. When the vulnerable driver performs spi_read(), it supplies a stack-based buffer to an SPI transfer path that may use DMA. Because the buffer is not DMA-safe, the DMA operation can interact incorrectly with kernel stack memory. Repeated or carefully timed ADC read operations may cause memory corruption, kernel faults, information disclosure, or potentially controlled corruption that could be developed into local privilege escalation. Exploitation is hardware- and configuration-dependent, requiring the vulnerable driver to be loaded and the affected ADC/SPI path to be reachable.

How to fix it

Upgrade to a Linux kernel release or vendor backport that contains the ti-adc161s626 fix using DMA-safe memory for spi_read(). No exact fixed version was provided in the input, so use the fixed kernel package version published by the operating system, appliance, or device vendor. Where immediate patching is not possible, mitigate by disabling or unloading the ti-adc161s626 driver if the ADC is not required, restricting local access to IIO device nodes and sysfs sensor interfaces, limiting untrusted local shell access, and applying device cgroup, udev, or container policies that prevent untrusted workloads from interacting with the affected hardware interface.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the vulnerable ti-adc161s626 driver and whether the affected ADC device is present and accessible. Validate remediation by confirming the installed kernel package includes the upstream or vendor backported patch that replaces the stack spi_read() buffer with a DMA-safe buffer. After patching, reboot into the fixed kernel, verify the running kernel version, confirm the module build date/version changed where applicable, and test ADC read functionality while monitoring kernel logs for SPI, DMA, IIO, or kernel oops messages. Systems without the driver loaded and without the affected ADC hardware/interface exposed are unlikely to be exploitable through this flaw.

Typical attack path

1. Gain local authenticated access to a Linux system using the affected kernel and ti-adc161s626 driver.
2. Confirm the affected ADC device is present and exposed through the Linux Industrial I/O subsystem.
3. Trigger ADC read operations through available local interfaces or through software that reads the sensor.
4. Cause the driver to pass stack memory to spi_read() on an SPI controller path that may use DMA.
5. Leverage the resulting unsafe DMA behavior to crash the kernel, corrupt kernel memory, disclose memory, or attempt privilege escalation.

How to detect it

Look for evidence of local interaction with the affected Industrial I/O ADC interface followed by kernel instability. Useful sources include kernel logs, system journal entries, crash dumps, audit logs for access to IIO sysfs paths or /dev/iio device nodes, EDR telemetry for local processes repeatedly reading ADC interfaces, and module inventory showing ti-adc161s626 loaded. Indicators are most likely to appear as kernel oops, panic, DMA mapping errors, SPI transfer failures, IIO read errors, or faults referencing ti-adc161s626, spi_read, SPI, DMA, or the Industrial I/O subsystem. Because no public exploit or KEV exploitation is reported, there are no known attacker-specific network indicators; detection should focus on anomalous local access patterns and crash artifacts on systems with the affected driver.

• ti-adc161s626
• adc161s626
• /sys/bus/iio/devices/
• /dev/iio:device
• spi_read
• DMA-safe
• kernel BUG
• kernel NULL pointer dereference
• general protection fault
• Unable to handle kernel paging request
• Oops:
• Kernel panic
• DMA-API:
• spi transfer failed
• iio: adc

What your security team should do

• Prioritize patching Linux systems, embedded devices, and appliances that use the TI ADC161S626 ADC driver or expose Industrial I/O ADC interfaces to local users or workloads.
• Obtain fixed kernel packages or vendor firmware updates and verify that the running kernel, not only the installed package, has been updated after reboot.
• Inventory systems for the ti-adc161s626 module, IIO ADC devices, SPI controllers, and user-accessible sensor interfaces.
• Restrict access to /sys/bus/iio, /dev/iio:device*, and related ADC-reading services to trusted users only until patched.
• Disable or blacklist the ti-adc161s626 driver where the hardware function is not operationally required.
• Monitor kernel logs for crashes, DMA mapping errors, SPI transfer errors, and repeated ADC read failures that may indicate probing or exploitation attempts.
• Treat unexplained kernel crashes on affected hardware as potentially security-relevant and preserve logs, crash dumps, and kernel versions for analysis.