CVE-2026-19947: Missing kernel object permission check in devmux syscalls allows unprivileged user threads to retarget a device multiplexer
The device multiplexer pseudo-driver in drivers/misc/devmux/devmux.c exposes two system calls, devmuxselectget() and devmuxselectset(). When CONFIGUSERSPACE is enabled, their user-mode verifiers zvrfydevmuxselectget() and zvrfydevmuxselectset() forwarded directly to the kernel implementations without performing any kernel-object validation — no kobjectaccesscheck() and no driver object check. Compounding this, DEVICEDTINSTDEFINE() registered devmux instances with a NULL driver API pointer, which causes scripts/build/genkobjectlist.py to skip them entirely, so a devmux device had no struct kobject 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 DEVICEDTGET(DTNODELABEL(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 CONFIGUSERSPACE=y together with the experimental CONFIGDEVMUX=y (which depends on CONFIGDEVICEMUTABLE) 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 devmuxdriverapi and attaches a DEVICEAPI(devmux, devmuxapi) instance to each devmux device so that it becomes a tracked KOBJDRIVERDEVMUX kernel object, and adds KOOPS(devmuxinstget(dev) == SIZEMAX) plus KOOPS(kobjectaccesscheck(dev) != 0) to both verifiers.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
Exposure requires CONFIG_USERSPACE to be enabled and a devmux device instance to be present. Any user-mode thread in such a deployment can invoke the affected syscalls without having been granted access to that device.
What does an attacker need to exploit this?
The attacker needs the ability to run a thread in user mode. No prior permission on the devmux device is required, because the device pointer can be available to application code as a compile-time constant and the syscall verifiers did not validate object access.
What is the practical impact of successful exploitation?
An unprivileged user-mode thread can retarget a device multiplexer by calling devmux_select_get() or devmux_select_set(). The implementations validate device pointers against the static devmux instance table and bounds-check selection indexes, so the issue is an authorization bypass rather than a memory-safety flaw.