CVE-2026-79978 in Zephyr
Summary
by MITRE • 10/23/2026
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 <dev> 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in the ADXL345 sensor driver represents a critical out-of-bounds write condition rooted in improper buffer size validation and state management within the real-time I/O streaming subsystem. The core technical flaw resides in the adxl345_process_fifo_samples_cb function, which is responsible for processing data retrieved from the device's hardware FIFO. During operation, this callback calculates the amount of data to report by clamping the available FIFO bytes against the space actually returned by rtio_sqe_rx_buf. However, a logical inconsistency exists in how subsequent write operations are bounded. While the reported length is correctly limited, the driver proceeds to queue bus read requests for each hardware FIFO entry at consecutive offsets from the start of the buffer. Crucially, this iteration is controlled by the device-reported entry count rather than the clamped limit or the actual allocated buffer size. This discrepancy creates a scenario where the number of write operations exceeds the boundaries of the memory allocation provided by the RTIO allocator.
The operational impact of this flaw is severe data corruption and potential system instability. When the allocated buffer is smaller than a full batch of sensor data, which occurs frequently due to the nature of the RTIO block pool allocator, the driver writes up to 186 bytes past the end of the allocation. The rtio_block_pool_alloc function typically reduces requested sizes down one block at time until contiguous space is found, and drivers often request minimal sizes such as sizeof(struct adxl345_fifo_data) plus six bytes for overhead. If the memory pool's block granularity is smaller than a full FIFO batch, which can be 204 bytes depending on configuration, fragmentation or consumer lag will trigger this vulnerable code path. The out-of-bounds writes are executed via I2C or SPI RTIO backends, often utilizing DMA on many System-on-Chip architectures. These writes target the shared RTIO block pool, leading to silent corruption of neighboring live buffers used by other real-time consumers or memory beyond the pool itself if the allocation is particularly small.
A secondary but compounding defect exacerbates this issue through improper state reset logic. The data structure member fifo_total_bytes is not reset at the start of each batch processing cycle. Consequently, if a streaming chain is aborted or encounters an error mid-process, stale values remain in the driver's internal state. This residual state causes subsequent batches to calculate incorrect write offsets, pushing writes further out of bounds even if buffer sizes might otherwise have been sufficient for that specific instance. The combination of unbounded iteration and stale offset calculation ensures that memory corruption is not merely a theoretical edge case but a likely outcome under conditions of pool starvation or error recovery scenarios.
From an industry standards perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write, as the application writes data beyond the allocated buffer boundary. It also reflects aspects of CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization if the stale state interacts unpredictably with concurrent RTIO operations. In terms of attack vectors and tactics, this falls under ATT&CK technique T1074: Data Staged or Local Data Manipulation, specifically involving memory corruption that could lead to denial of service through system crashes. Although there is no direct network, USB, or radio path to exploit this code directly, the vulnerability can be triggered by a co-resident local workload that induces buffer-pool starvation. This makes it relevant for threat models focusing on local privilege escalation via resource exhaustion leading to memory corruption in embedded systems running Zephyr RTOS with CONFIG_ADXL345_STREAM enabled.
Mitigation strategies must address both the logical bounds checking and the state management issues within the driver code. The primary fix involves ensuring that the number of bus read requests queued is strictly bounded by the actual size of the buffer returned by rtio_sqe_rx_buf, rather than relying on device-reported entry counts which may exceed available memory space. Developers should implement explicit checks to verify that the cumulative offset of all writes does not surpass the allocated buffer length before queuing any DMA or I/O operations. Additionally, the fifo_total_bytes variable must be explicitly reset at the beginning of every batch processing cycle to prevent stale state from influencing subsequent operations during error recovery paths. System administrators and integrators should also consider configuring larger memory pool block sizes if possible, ensuring that allocations are less likely to fall below the threshold required for a full FIFO batch, thereby reducing the frequency with which this code path is exercised under normal load conditions.