Description

The flash_copy() system call is verified by z_vrfy_flash_copy() in drivers/flash/flash_util.c. On builds with CONFIG_USERSPACE enabled, this handler is the kernel-side trust boundary for a user-mode caller. Prior to the fix it validated only the output buffer (K_SYSCALL_MEMORY_WRITE) and passed the two struct device * arguments, src_dev and dst_dev, directly into the implementation without any object validation — unlike every sibling flash syscall, which guards its device pointer with K_SYSCALL_DRIVER_FLASH. A user-mode thread fully controls the values of src_dev/dst_dev and the contents of its own address space. The implementation z_impl_flash_copy() dereferences these pointers and calls through their driver-API function tables (e.g. api->get_parameters(dst_dev), flash_read(src_dev, ...), flash_write(dst_dev, ...)). By supplying a pointer to a forged struct device whose api table contains attacker-chosen function pointers, an unprivileged thread can cause the kernel to call arbitrary code in supervisor mode; passing any arbitrary or invalid address otherwise yields a kernel crash or out-of-bounds read. The result is a local privilege escalation out of the userspace sandbox (with kernel denial-of-service and information disclosure as lesser outcomes). The fix adds K_SYSCALL_DRIVER_FLASH(src_dev, read) and K_SYSCALL_DRIVER_FLASH(dst_dev, write) to z_vrfy_flash_copy(), which verify each device is a registered flash-driver kernel object the calling thread is permitted to use before any dereference, closing the path completely.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-17T17:16:57.720Z",
  "pubdate": "2026-08-17T17:16:57.720Z",
  "executiveSummary": "A privilege escalation vulnerability exists in the flash_copy() system call handler within the Zephyr RTOS flash driver utility subsystem when CONFIG_USERSPACE is enabled.\nThe flaw stems from insufficient input validation of the struct device pointers passed as arguments to the system call, failing to enforce kernel object validation unlike sibling flash system calls.\nAn unprivileged user-mode thread can supply forged struct device pointers containing attacker-controlled function pointers in their driver-API function tables.\nSuccessful exploitation allows a local attacker to achieve arbitrary code execution in supervisor mode, resulting in local privilege escalation, kernel denial-of-service, or information disclosure.\nThe exploitation vector requires a local attacker capable of executing user-mode threads within the system sandbox where CONFIG_USERSPACE is active.",
  "technicalDetails": "The vulnerability resides in the z_vrfy_flash_copy() verification function located in drivers/flash/flash_util.c, which acts as the kernel-side trust boundary for user-mode callers when CONFIG_USERSPACE is enabled.\nPrior to the fix, the validation logic exclusively verified the output buffer using K_SYSCALL_MEMORY_WRITE but omitted validation for the src_dev and dst_dev struct device * arguments.\nUnlike sibling flash system calls that correctly guard their device pointers using K_SYSCALL_DRIVER_FLASH, z_vrfy_flash_copy() passed unchecked pointers directly into the implementation layer, z_impl_flash_copy().\nA user-mode thread fully controls the values of src_dev and dst_dev within its address space. When z_impl_flash_copy() executes, it dereferences these pointers to invoke driver-API function tables, such as api->get_parameters(dst_dev), flash_read(src_dev, ...), and flash_write(dst_dev, ...).\nTo exploit this vulnerability, an attacker crafts a malicious pointer pointing to a forged struct device containing attacker-chosen function pointers inside its api table.\nWhen the kernel dereferences these pointers during execution of flash_copy(), it branches directly to the attacker-supplied addresses in supervisor mode.\nSupplying arbitrary or invalid addresses outside of code execution attempts yields a kernel crash via out-of-bounds reads or invalid memory dereferences, leading to kernel denial-of-service.\nAuthentication and privilege requirements are minimal from an OS perspective, requiring only the ability to execute unprivileged user-mode code within the restricted application environment.\nThe attack flow proceeds as follows: 1) The unprivileged thread allocates a fake struct device structure in user memory with a manipulated api function pointer table. 2) The thread invokes the flash_copy() system call, passing pointers to the forged device structures. 3) The unvalidated pointers bypass z_vrfy_flash_copy() checks and reach z_impl_flash_copy(). 4) The kernel dereferences the forged api pointers, transferring control to attacker-chosen code in supervisor mode and achieving local privilege escalation."
}