CVE-2026-79978

The RTIO streaming completion callback adxl345 process fifo samples cb() in drivers/sensor/adi/adxl345/adxl345 stream.c clamps the amount of FIFO data it will report (read len = MIN(fifo bytes, buf avail)) to the space actually returned by rtio sqe rx buf(), but then queues one 6-byte bus read per hardware FIFO entry at consecutive offsets from read buf, bounded by the device-reported entry count rather than by the clamp. When the allocated buffer is smaller than a full batch, the driver writes up to 186 bytes past the end of the allocation; a companion defect left data->fifo total bytes un-reset at batch start, so an aborted or errored chain could leave a stale write offset that pushes the next batch's writes out of bounds as well.

A short buffer is an expected, first-class outcome of the RTIO allocator: rtio block pool alloc() walks the requested size down one block at a time until a contiguous run is available, and the driver only demands sizeof(struct adxl345 fifo data) + 6 bytes as its minimum. Any streaming configuration whose mempool block granularity is smaller than a full FIFO batch (204 bytes) — for example the sensor shell's RTIO DEFINE WITH MEMPOOL(sensor read rtio, 8, 8, 32, 64, 4) used by sensor stream on fifo wm incl, or the 16-byte-block streaming example in the documentation — takes this path whenever the pool is fragmented or the consuming thread falls behind.

The out-of-bounds writes are performed by the I2C/SPI RTIO backend (DMA on many SoCs) into the shared RTIO block pool, corrupting neighbouring live buffers or, for a pool smaller than one batch, memory beyond the pool itself. The written bytes are accelerometer samples and the destination follows the allocation, so there is no controllable corruption primitive: the realistic impact is silent corruption of other RTIO consumers' data or a crash. Reaching it requires a board with an interrupt-wired ADXL345 built with CONFIG ADXL345 STREAM, plus buffer-pool starvation, which a co-resident local workload can induce but which also occurs spontaneously under load; there is no network, USB or radio path to this code.