CVE-2026-19575

7.8 HIGHpublic exploit available

Published 2026-10-09 · Updated 2026-10-09

AI risk analysis

Summary: The flaw allows user-mode threads to pass any kernel object to device_deinit() instead of validating its actual type, enabling attackers to craft malicious device structures that can trigger arbitrary code execution in supervisor mode with read/write access to kernel memory.
Exploitability: Exploitation is moderately difficult and requires a user thread with permission to allocate or hold kernel objects, particularly thread stacks, but the attack surface is well-defined and the primitive is powerful enough to achieve full kernel RCE.
Blast radius: If exploited, this vulnerability could allow unprivileged local users to gain full kernel code execution capabilities, potentially leading to complete system compromise through privilege escalation.
Detection: No reliable host or network indicator is derivable from the published description.
Prioritized remediation: Upgrade to Zephyr OS version 2.590 or later where the device_deinit() syscall handler properly validates object types.

kernelprivilege-escalationrcezephyr

Analysis generated locally by garnet-coder (no data left the box). AI-assisted — verify against primary sources before acting.

NVD description

The user-mode verification handler for the device_deinit() system call, z_vrfy_device_deinit() in kernel/device.c, validated its dev argument with K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY). k_object_validate() short-circuits its type comparison when the requested type is K_OBJ_ANY, so the check reduced to "this pointer is the base address of some kernel object the calling thread has been granted" — the object's actual type was never compared, and K_SYSCALL_OBJ_INIT also skips the initialization-state check. The sibling handlers z_vrfy_device_init() and z_vrfy_device_is_ready() already used K_OBJ_DRIVER_ANY and were unaffected. A thread running in user mode can therefore pass any kernel object it holds permission on — most usefully a thread stack object obtained from the k_thread_stack_alloc() syscall or a statically defined K_THREAD_STACK it was granted in order to spawn a child user thread — whose backing memory is writable from user mode. z_impl_device_deinit() then interprets those attacker-written bytes as a struct device: it dereferences the state pointer read out of the object, calls the function pointer read out of ops.deinit, and on success writes through state again. The result is an indirect call to an arbitrary address executed in supervisor mode, plus an arbitrary kernel read and a single-byte kernel write. Exploitation gives a local unprivileged thread full kernel code execution, defeating the CONFIG_USERSPACE isolation boundary entirely; a less precise attempt yields a supervisor-mode fault and a system crash. The defect is only reachable in builds that enable both CONFIG_USERSPACE and CONFIG_DEVICE_DEINIT_SUPPORT — with de-initialization support disabled, z_impl_device_deinit() returns -ENOTSUP without ever dereferencing the pointer. In v4.2.x and v4.3.x, CONFIG_DEVICE_DEINIT_SUPPORT defaulted to y, so every CONFIG_USERSPACE build of those releases is exposed unless the option was explicitly turned off. From v4.4.0 the option is opt-in (no default, and not selected by any in-tree subsystem), so a v4.4.x build is exposed only if it enables the option explicitly. The v4.2 line is no longer maintained and receives no backport. The fix changes the object check to K_OBJ_DRIVER_ANY, which constrains the argument to the build-generated driver object type range (K_OBJ_DRIVER_FIRST..K_OBJ_DRIVER_LAST) — the real struct device instances placed by the linker — so the state and ops.deinit fields are once again kernel-controlled.

CVSS vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Weaknesses

CWE-843

Public exploit & PoC references

All references

Source data: NVD (nvd.nist.gov), public domain. Exploit-DB.ai adds local AI analysis for defensive use only.

Related CVEs

Related by shared AI tags and CWE weakness class. Browse the full archive.