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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-09T08:16:55.057Z",
  "pubdate": "2026-10-09T08:16:55.057Z",
  "executiveSummary": "This vulnerability is an improper kernel object type validation flaw in the Zephyr real-time operating system's device management subsystem.\nThe issue permits a local unprivileged user-mode thread to trigger arbitrary kernel-mode code execution by supplying an improperly validated object pointer to the device_deinit() system call.\nImpact includes a complete compromise of the CONFIG_USERSPACE isolation boundary, allowing an attacker to escalate privileges to supervisor mode.\nAffected systems are those configured with both CONFIG_USERSPACE and CONFIG_DEVICE_DEINIT_SUPPORT.\nVersions v4.2.x and v4.3.x are significantly impacted due to the default enabling of device de-initialization support, while v4.4.0 and later are only vulnerable if the configuration option is explicitly enabled.\nThe vulnerability represents a critical security risk as it facilitates kernel-level exploitation from an unprivileged, sandboxed context.",
  "technicalDetails": "The root cause of the vulnerability resides in the user-mode verification handler, z_vrfy_device_deinit() within kernel/device.c. The implementation utilizes K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY) to validate the dev argument. Because K_OBJ_ANY instructs k_object_validate() to bypass specific type checking, the validator only confirms that the pointer corresponds to a kernel object the calling thread possesses permissions for, failing to verify that the object is specifically a struct device.\nAn attacker can exploit this by utilizing any kernel object they have access to, such as a user-accessible thread stack object. By populating the memory region of the chosen object with attacker-controlled data mimicking a struct device, the attacker can influence the pointers used by the kernel.\nThe attack flow proceeds as follows: First, the attacker allocates or acquires permission to an object residing in user-writable memory (e.g., a thread stack). Second, the attacker crafts a malicious structure within this memory, specifically populating the state pointer and the ops.deinit function pointer. Third, the attacker invokes the device_deinit() system call, passing the address of this forged structure as the dev argument. Fourth, z_vrfy_device_deinit() passes the object validation check due to the use of K_OBJ_ANY. Finally, the kernel-mode implementation z_impl_device_deinit() executes, dereferencing the attacker-controlled state pointer and invoking the malicious function pointer found in the forged ops.deinit field. This results in an indirect branch to an arbitrary memory address with supervisor privileges.\nThe vulnerability requires local access and the presence of both CONFIG_USERSPACE and CONFIG_DEVICE_DEINIT_SUPPORT. In v4.2.x and v4.3.x, these configurations were common, facilitating exploitation. In v4.4.x, the risk is reduced as CONFIG_DEVICE_DEINIT_SUPPORT is no longer enabled by default.\nSuccessful exploitation grants the attacker full control over the supervisor-mode execution context. Failed exploitation attempts typically result in a supervisor-mode fault, leading to a system crash (denial of service). The fix involves updating the validation macro to K_OBJ_DRIVER_ANY, which restricts input strictly to legitimate, build-generated driver objects within the valid linker-defined range."
}