CVE-2026-64504: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-64504 Overview

CVE-2026-64504 is a stack out-of-bounds write vulnerability in the Linux kernel's Industrial I/O (IIO) subsystem, specifically in the BMC150 accelerometer driver. The flaw resides in __bmc150_accel_fifo_flush(), which trusts the device-reported FIFO frame count without clamping it against the fixed on-stack buffer size. A malfunctioning, malicious, or counterfeit accelerometer, or an attacker tampering with the I2C/SPI bus, can report up to 127 frames and trigger a write of up to 762 bytes into a 192-byte buffer. The overflow can clobber the stack canary, saved registers, and the return address.

Critical Impact
A hardware-level attacker on the I2C/SPI bus can trigger a stack buffer overflow of up to 570 bytes in kernel context, potentially leading to kernel memory corruption and code execution.

Affected Products

Linux Kernel — IIO accelerometer driver bmc150
Systems using Bosch BMC150 accelerometers connected via I2C or SPI
Multiple stable kernel branches (see fix commits in references)

Discovery Timeline

2026-07-25 - CVE-2026-64504 published to NVD
2026-07-25 - Last updated in NVD database

Technical Details for CVE-2026-64504

Vulnerability Analysis

The vulnerability lives in drivers/iio/accel/bmc150-accel-core.c within __bmc150_accel_fifo_flush(). The function allocates a stack buffer sized for the hardware maximum: u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3], where BMC150_ACCEL_FIFO_LENGTH is 32. This yields a 192-byte buffer intended to hold at most 32 three-axis samples.

The driver then reads the frame count from the device's FIFO_STATUS register and applies only a 7-bit mask: count = val & 0x7F. This permits values from 0 to 127. The only additional check is an optional caller-supplied sample budget that does not apply on the flush-all path where samples == 0.

The function then invokes bmc150_accel_fifo_transfer(data, (u8 *)buffer, count), which reads count * 6 bytes via regmap. With count = 127, the transfer writes 762 bytes into a 192-byte buffer, resulting in a stack out-of-bounds write of up to 570 bytes.

Root Cause

The root cause is missing input validation on device-supplied length data. The driver assumes the sensor will report a legal frame count no larger than the hardware FIFO depth, but the register field width allows values well beyond that. This is a classic stack buffer overflow (CWE-121) driven by an untrusted hardware value.

Attack Vector

Exploitation requires the attacker to control the value returned by the BMC150 sensor. This is possible through a counterfeit or firmware-modified accelerometer, physical tampering with the I2C or SPI bus, or a supply-chain compromise. When a FIFO flush occurs, the oversized transfer overwrites the stack canary, saved registers, and the return address in kernel context. The upstream fix clamps count to BMC150_ACCEL_FIFO_LENGTH before the transfer, mirroring the existing watermark clamp in bmc150_accel_set_watermark().

Detection Methods for CVE-2026-64504

Indicators of Compromise

Kernel stack protector panics or Oops messages referencing __bmc150_accel_fifo_flush or bmc150_accel_fifo_transfer.
Unexpected kernel crashes on devices equipped with BMC150 accelerometers, particularly during IIO buffer flush operations.
Abnormal I2C or SPI traffic showing FIFO_STATUS reads returning counts greater than 32.

Detection Strategies

Audit deployed kernel versions against the fix commits listed in the references to identify unpatched systems.
Monitor kernel logs for stack canary violations (Kernel stack is corrupted) tied to IIO driver frames.
Where feasible, use bus analyzers on I2C/SPI lines to detect anomalous accelerometer register responses.

Monitoring Recommendations

Collect and centralize dmesg and journalctl -k output from Linux fleets using accelerometers for review of kernel panics.
Track kernel build hashes and package versions across the fleet to confirm patch coverage on IIO-enabled kernels.
Alert on repeated reboots or watchdog resets on IoT and embedded devices that ship with the BMC150 sensor.

How to Mitigate CVE-2026-64504

Immediate Actions Required

Apply the upstream Linux kernel patches that clamp count to BMC150_ACCEL_FIFO_LENGTH in __bmc150_accel_fifo_flush().
Update to a stable kernel release that incorporates the fix commits listed in the references section.
Inventory devices using the bmc150_accel module to prioritize patching for at-risk endpoints.

Patch Information

The fix is available across multiple stable branches. Relevant commits include 2fe0531, 35a3cd8, 3e76652, 89f4a4c, b5a9f52, bfffc98, ce0e1ca, and d0e6d92. Rebuild and redeploy affected kernels after applying the appropriate backport.

Workarounds

Unload the bmc150_accel, bmc150_accel_i2c, and bmc150_accel_spi modules on systems that do not require accelerometer functionality.
Blacklist the driver via /etc/modprobe.d/ on systems where the sensor is not used, preventing the vulnerable code path from executing.
Ensure physical security controls limit adversary access to the I2C/SPI bus and to the accelerometer hardware itself.

bash

# Blacklist the vulnerable driver until the kernel is patched
echo "blacklist bmc150_accel"     | sudo tee /etc/modprobe.d/bmc150-cve-2026-64504.conf
echo "blacklist bmc150_accel_i2c" | sudo tee -a /etc/modprobe.d/bmc150-cve-2026-64504.conf
echo "blacklist bmc150_accel_spi" | sudo tee -a /etc/modprobe.d/bmc150-cve-2026-64504.conf
sudo update-initramfs -u
sudo reboot