PT-2026-64725 · Linux · Linux
CVE-2026-64504
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux