CVE-2026-19947Medium· 5.3▾ SunlitThe device multiplexer pseudo-driver in drivers/misc/devmux/devmux.c exposes two system calls, devmux_select_get() and devmux_select_set(). When CONFIG_USERSPACE is enabled, their user-mode verifiers z_vrfy_devmux_select_get() and z_vrfy…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 29.2 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
The device multiplexer pseudo-driver in drivers/misc/devmux/devmux.c exposes two system calls, devmux_select_get() and devmux_select_set(). When CONFIG_USERSPACE is enabled, their user-mode verifiers z_vrfy_devmux_select_get() and z_vrfy_devmux_select_set() forwarded directly to the kernel implementations without performing any kernel-object validation — no k_object_access_check() and no driver object check. Compounding this, DEVICE_DT_INST_DEFINE() registered devmux instances with a NULL driver API pointer, which causes scripts/build/gen_kobject_list.py to skip them entirely, so a devmux device had no struct k_object and no permission on it could be granted or withheld in the first place.
Any thread running in user mode can reach the defect: device pointers such as DEVICE_DT_GET(DT_NODELABEL(devmux0)) are compile-time constants available to application code, and the syscall accepted them from a thread that had never been granted access to the device. The kernel implementations do validate the pointer against the static devmux instance table and bounds-check the selection index, so this is not a memory-safety issue; the failure is purely one of authorization. Exposure requires CONFIG_USERSPACE=y together with the experimental CONFIG_DEVMUX=y (which depends on CONFIG_DEVICE_MUTABLE) and a zephyr,devmux devicetree node.
An unprivileged user-mode thread can read and change which downstream device a multiplexer forwards to, bypassing the userspace object-permission model. Because a devmux forwards the data, configuration and API of the selected device — its documented use being zephyr,console and zephyr,shell-uart switching — an attacker can suppress console, log and shell output, redirect that output to a downstream device it is able to observe, or flip the selection underneath another thread that is legitimately using the multiplexer. The impact is bounded to the devicetree-fixed set of downstream devices; no out-of-bounds access or arbitrary pointer dereference is reachable.
The fix declares __subsystem struct devmux_driver_api and attaches a DEVICE_API(devmux, devmux_api) instance to each devmux device so that it becomes a tracked K_OBJ_DRIVER_DEVMUX kernel object, and adds K_OOPS(devmux_inst_get(dev) == SIZE_MAX) plus K_OOPS(k_object_access_check(dev) != 0) to both verifiers.
zephyr >= 3.6.0 < 4.5.0Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-17053Medium· 4.4The SMBus driver API exposed smbus_smbalert_remove_cb() and smbus_host_notify_remove_cb() as Zephyr syscalls
CVE-2026-78117Medium· 4.2Race condition on shared HCI TX descriptor in the Infineon PSOC 6 BLESS Bluetooth driver can leak adjacent memory over the air
CVE-2026-78116Medium· 5.2Double free of an RTIO submission in the Broadcom AFBR-S50 sensor driver data-evaluation error path
CVE-2026-19676High· 7.8PECI transfer syscall verifier does not validate embedded user buffer pointers, allowing arbitrary kernel memory read/write from user mode
CVE-2026-18748Low· 3.5Out-of-bounds read in Bluetooth Classic A2DP codec information element handling
CVE-2026-79976High· 7.1NULL pointer dereference in the MCTP I2C+GPIO target binding triggerable by a peer I2C controller