---
id: "CVE-2026-78116"
kind: "vulnerability"
aliases: ["CVE-2026-78116"]
title: "Zephyr: AFBR-S50 sensor driver double-completes RTIO submissions, corrupting memory"
severity: "medium"
cvss: 5.2
epss: 0.00169
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["embedded", "package", "rtio", "sensors", "zephyr"]
not_affected_if: ["no-afbr-s50-driver", "no-brcm-afbr-s50-node"]
published_at: "2026-10-21T19:17:03+00:00"
first_seen_at: "2026-10-23T21:57:29+00:00"
updated_at: "2026-10-25T04:28:46+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78116", "first_seen_at": "2026-10-23T21:57:29+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-78116", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Zephyr: AFBR-S50 sensor driver double-completes RTIO submissions, corrupting memory

When the Broadcom AFBR-S50 time-of-flight sensor driver fails to evaluate sensor data, it finalises the same RTIO request twice, which frees a pool entry and re-queues it. The result is corrupted submission pool bookkeeping, writes through released buffers and duplicate completions, which mainly causes memory corruption and loss of availability rather than code execution.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the build enables the AFBR-S50 driver: look for `brcm,afbr-s50` in the device tree or `CONFIG_AFBR_S50` in the project configuration.
- Compare the Zephyr tree version against the fixed release; the sources do not name the fixed version, so `unknown`.

## Fix

- Update Zephyr to a release containing the fix for CVE-2026-78116; the fixed version is `unknown` from these sources.
- Until updated, stop instantiating the `brcm,afbr-s50` driver if the sensor is not needed.

## Timeline

- 2026-10-23T21:57:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-78116
- 2026-10-24T13:15:54+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-78116

## From the sources

The Broadcom AFBR-S50 time-of-flight sensor driver double-completes an RTIO submission when sensor data evaluation fails. In data_ready_work_handler() (drivers/sensor/broadcom/afbr_s50/afbr_s50.c), a non-STATUS_OK return from Argus_EvaluateData() calls handle_error_on_result(), which finalises the request with rtio_iodev_sqe_err(), but execution then fell through to the tail of the function and finalised the very same struct rtio_iodev_sqe a second time with rtio_iodev_sqe_ok(). Unlike the other error branches in the same function, this one did not return.

Both completion helpers reach rtio_executor_done() in subsys/rtio/rtio_executor.c, which returns the submission to the pool via rtio_sqe_pool_free() and, for streaming (multishot) submissions, also releases the RX buffer with rtio_release_buffer(). The second completion therefore reads a freed rtio_iodev_sqe, pushes the same mpsc node onto the submission queue while it is already on the pool free list — splicing the two lists together — and re-submits the freed request so the next measurement is written through an already-released buffer. For one-shot submissions it emits a spurious success completion carrying stale userdata and frees the same pool entry twice.

The failure branch is driven by sensor conditions rather than by host software. The vendor API documents statuses such as ERROR_ARGUS_BIAS_VOLTAGE_REINIT and ERROR_ARGUS_LASER_MONITOR_INACTIVE as transient results of harsh ambient light, so a party in front of the optical sensor can provoke the invalid-data condition without any physical contact with the board or any software access; SPI transfer errors reach the same branch. In releases before the payload.Status check was dropped, ordinary sharp distance transitions in the sensor's field of view were sufficient.

Impact is corruption of the RTIO submission pool and mempool bookkeeping: aliased submissions, writes through released buffers, and duplicate completions delivered to the application. The attacker does not control the corrupted content, so the practical consequence is memory corruption and loss of availability on devices that instantiate brcm,afbr-s50, rather than directed code execution. Only builds that enable this driver are affected.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_