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
<pre>
u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3];
</pre>
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:
<pre>
count = val & 0x7F;
</pre>
so it can be 0..127. The only other limit applied to it is the optional
caller-supplied sample budget:
<pre>
if (samples && count > samples)
count = samples;
</pre>
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[]:
<pre>
bmc150_accel_fifo_transfer(data, (u8 *)buffer, count);
</pre>
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.