Cloudanix VulnDB

CVE-2026-64504

None

CVSS

—

EPSS

0.2%

Published

Jul 25, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Some Linux devices with a specific motion sensor can be crashed, and potentially more severely compromised, if the sensor or its hardware connection is malicious or faulty.

Exploitation
Physical Access
Attacker needs
Physical Access
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This is a Linux kernel stack buffer overflow in the Industrial I/O BMC150 accelerometer driver. During FIFO flush handling, the driver trusts the accelerometer-reported FIFO frame count after masking it to 7 bits, allowing values up to 127 even though the on-stack destination buffer is sized for only 32 samples. A malicious, counterfeit, malfunctioning, or bus-tampered I2C/SPI accelerometer can cause the kernel to read up to 762 bytes into a 192-byte stack buffer, overwriting adjacent stack data such as the stack canary, saved registers, and potentially the return address. Practical outcomes range from a kernel crash to possible kernel-mode code execution, depending on platform protections, exploit reliability, and attacker control over transferred data.

Why it matters to the business

The most likely operational impact is device instability or denial of service on Linux systems that load the affected BMC150 accelerometer driver and communicate with an untrusted or compromised sensor. Because exploitation requires control over the physical sensor, a counterfeit component, malicious peripheral, or tampering with the I2C/SPI bus, broad internet-scale exploitation is unlikely; the current EPSS is low, it is not in CISA KEV, and no public exploit maturity is reported. The risk is higher for embedded, IoT, industrial, kiosk, mobile, or appliance-style Linux systems where accelerometer hardware is present, components may be field-replaceable, or physical access is plausible.

How an attack unfolds

An attacker first needs a path to influence the BMC150-compatible accelerometer interface, such as replacing the sensor with a malicious or counterfeit device, modifying firmware in an attached component, or tampering with the I2C/SPI bus. When the Linux kernel driver performs a FIFO flush, the hostile device reports a FIFO frame count greater than the driver’s 32-frame buffer capacity, up to the 7-bit maximum of 127. On affected kernels, the driver does not clamp this value before transferring FIFO data into a fixed-size stack buffer. The kernel then copies more sample data than the buffer can hold, corrupting the kernel stack. In many cases this will trigger a stack-protector failure, kernel oops, panic, or reboot. With sufficient control over the data returned by the device and a target-specific exploit, the corruption could potentially be shaped into kernel control-flow hijacking, but exploitation is hardware-adjacent and significantly constrained compared with remote software-only vulnerabilities.

How to fix it

Upgrade to a Linux kernel version that includes the BMC150 accelerometer FIFO frame-count clamp fix. If a vendor-maintained kernel is used, apply the vendor security update rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by disabling the BMC150 accelerometer driver on systems that do not require it, preventing autoload of the related modules, or removing access to untrusted accelerometer hardware. Potential module names to review include bmc150_accel_core, bmc150_accel_i2c, and bmc150_accel_spi. For embedded products, validate the complete firmware image, kernel configuration, device tree or ACPI enumeration, and hardware supply chain, because the vulnerable code is only reachable when the affected driver is present and bound to hardware.

How to confirm the fix worked

Confirm that the running kernel contains the fix by checking the vendor advisory, package changelog, or kernel source for logic that clamps the FIFO frame count to BMC150_ACCEL_FIFO_LENGTH before bmc150_accel_fifo_transfer() is called. Verify the running kernel version after reboot, not just the installed package version. Check whether the driver is present or loaded using module inventory and kernel logs, and confirm whether any BMC150 IIO devices are enumerated under sysfs. On systems where the device is required, regression-test accelerometer FIFO reads and flushes to ensure normal sensor operation continues. On systems where mitigation is to disable the driver, confirm that the relevant modules cannot be loaded and that no BMC150 accelerometer device binds at boot.

Typical attack path

  1. Identify a Linux target that uses or loads the BMC150 accelerometer Industrial I/O driver.
  2. Gain the ability to influence the accelerometer or its I2C/SPI communication path through physical access, component substitution, malicious peripheral hardware, or bus tampering.
  3. Cause the device to report a FIFO frame count greater than 32 during a driver FIFO flush operation.
  4. Return enough FIFO sample bytes for the driver to copy count * 6 bytes into the undersized stack buffer.
  5. Trigger kernel stack corruption, typically causing a stack-protector alert, kernel oops, panic, reboot, or potentially controlled kernel execution on a vulnerable and suitably configured target.

How to detect it

Retrospective detection should focus on kernel and boot logs, crash dumps, and hardware-maintenance records because exploitation is expected to manifest as kernel instability rather than conventional network indicators. Review journald, dmesg, syslog, pstore, ramoops, kdump/vmcore, and embedded crash telemetry for stack-smashing, kernel oops, panic, or watchdog reset events referencing the BMC150 accelerometer driver, Industrial I/O subsystem, I2C, or SPI around the time of unexpected reboots. Look for repeated sensor FIFO activity followed by a crash, driver probe/bind messages for bmc150_accel shortly before instability, and bus errors that may indicate tampering or malfunctioning hardware. If physical compromise is plausible, inspect device servicing history, component substitutions, board-level tampering evidence, and unexpected changes to device tree, ACPI tables, or firmware images that cause the driver to load. There are no known public malware file indicators or network indicators for this vulnerability based on the supplied information.

  • bmc150_accel
  • bmc150-accel
  • bmc150_accel_fifo_flush
  • bmc150_accel_fifo_transfer
  • drivers/iio/accel/bmc150-accel-core.c
  • stack smashing detected
  • Kernel panic - not syncing
  • kernel BUG
  • Oops:
  • general protection fault
  • invalid opcode
  • watchdog: BUG: soft lockup
  • iio: accel
  • /sys/bus/iio/devices/
  • /lib/modules/*/kernel/drivers/iio/accel/bmc150-accel-core.ko
  • /lib/modules/*/kernel/drivers/iio/accel/bmc150-accel-i2c.ko
  • /lib/modules/*/kernel/drivers/iio/accel/bmc150-accel-spi.ko
  • bmc150_accel_core
  • bmc150_accel_i2c
  • bmc150_accel_spi

What your security team should do

  • Inventory Linux systems, firmware images, and embedded products for BMC150 accelerometer support or loaded bmc150_accel-related modules.
  • Prioritize patching for physically exposed, field-deployed, industrial, IoT, kiosk, appliance, mobile, or supply-chain-sensitive devices that include accelerometer hardware.
  • Apply vendor kernel updates containing the frame-count clamp fix; if no update is available, disable or blocklist the BMC150 accelerometer driver where operationally acceptable.
  • Review procurement and hardware-integrity controls for devices that rely on I2C/SPI sensors, especially where replacement components or peripheral access are possible.
  • Monitor kernel logs for stack-protector failures, oopses, panics, or I2C/SPI anomalies involving the BMC150 accelerometer driver.
  • Treat unexpected crashes in this driver as potential hardware tampering or component failure events, not only as software reliability issues.

The record

In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: clamp the device-reported FIFO frame count __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: count = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: if (samples && count > samples) count = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: bmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address. Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.

Affected packages

Ecosystem Package Introduced Fixed