VulnerabilityPublished 25 Jul 2026

CVE-2026-64504: Linux kernel · iio: accel: bmc150: clamp the device-reported FIFO frame count

Source GCVE Database

Not known to be exploited.

Data as of 26 Oct 2026, 13:47 UTC

Severity

High

Rated by Threat Radar · No CVSS score from NVD or the CNA

EPSS: 0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.

Exploitation evidence

Disclosed: evidence found.
CVE published 25 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

ghsa-4j8x-6qx9-p4gc

What to do

AI-suggested

A fix is available that clamps the device-reported FIFO frame count to the buffer size before data transfer, preventing the stack overflow. Users should apply the official Linux kernel update that includes this fix. Since this is a kernel vulnerability, updating to a patched kernel version is the recommended remediation. Patch status is not explicitly confirmed in the provided data; users should consult the official Linux kernel advisories or vendor patches for the exact fixed versions and apply them accordingly.

Description

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.

Impact

An attacker controlling a malfunctioning, malicious, or counterfeit accelerometer device, or able to tamper with the I2C/SPI bus, can cause a stack buffer overflow in the kernel driver. This overflow can overwrite critical stack data, potentially leading to kernel memory corruption and arbitrary code execution or system compromise. However, no known exploits in the wild have been reported.

Summary

The Linux kernel's bmc150 accelerometer driver (__bmc150_accel_fifo_flush function) copies the number of samples reported by the device's FIFO into a fixed-size on-stack buffer sized for 32 samples. The frame count is read from the FIFO_STATUS register and masked to 7 bits, allowing values up to 127. Without proper clamping, this count can exceed the buffer size, leading to a stack out-of-bounds write of up to 570 bytes when transferring data. This overflow can overwrite critical stack data such as the stack canary, saved registers, and return address. The vulnerability arises from insufficient validation of the frame count before the data transfer. The fix clamps the frame count to the buffer size (32 samples), preventing overflow. Legitimate devices do not report more than 32 frames, so normal operation is unaffected.

References

Community reviews

Loading reviews…