CVE-2026-87039 in Zephyr
Summary
by MITRE • 11/04/2026
The user-mode syscall verifier z_vrfy_i2s_configure() in drivers/i2s/i2s_handlers.c copies the caller's struct i2s_config in from user memory and then, when cfg->frame_clk_freq is 0 (the API's "unconfigure the stream" request), jumps straight to z_impl_i2s_configure() without performing the K_SYSCALL_OBJ(config.mem_slab, K_OBJ_MEM_SLAB) ownership/type check or the block_size sanity check. The mem_slab field is a struct k_mem_slab *, so on that path a completely unvalidated, user-chosen pointer reaches driver code that is entitled to trust it as a real kernel object.
Any thread running under CONFIG_USERSPACE that has access to an I2S device object can trigger this with a single i2s_configure() call. Most in-tree drivers special-case frame_clk_freq == 0 and never store the caller's structure, but drivers/i2s/i2s_litex.c does not: i2s_litex_configure() only logs a warning for a mismatched frame clock, then memcpy()s the caller's config into stream->cfg and marks the stream I2S_STATE_READY. A subsequent i2s_trigger() with I2S_TRIGGER_START enables the FIFO interrupt, and the interrupt handlers i2s_litex_isr_rx() / i2s_litex_isr_tx() then call k_mem_slab_alloc() and k_mem_slab_free() on the attacker-supplied pointer in supervisor context.
The result is an arbitrary-pointer read/write primitive executed by the kernel on behalf of an unprivileged thread — k_mem_slab_alloc() takes a spinlock at slab->lock and reads and writes slab->free_list and the link word inside the returned "block" — which defeats the CONFIG_USERSPACE isolation boundary entirely. The same missing validation is a hazard for out-of-tree I2S drivers that retain the configuration on the unconfigure path. Builds without CONFIG_USERSPACE are unaffected, since the verifier is not used.
The fix zeroes config.mem_slab and config.block_size on the unconfigure path so the driver can never receive an unvalidated pointer, while still allowing a stream to be unconfigured by a caller that does not own a memory slab, as the API documents.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
A critical vulnerability exists within the Zephyr real-time operating system kernel in the user-mode syscall verifier for I2S configuration operations. Specifically, the function z_vrfy_i2s_configure located in drivers/i2s/i2s_handlers.c fails to perform necessary validation checks when a process requests to unconfigure an audio stream by passing zero as the frame clock frequency parameter. Under normal circumstances, this API call should trigger comprehensive security verifications including ownership and type checking of memory slab objects via K_SYSCALL_OBJ. However, due to a logic error in the control flow, the verifier bypasses these critical safety mechanisms when cfg->frame_clk_freq is equal to zero. This oversight allows an unprivileged user-space thread to supply arbitrary kernel pointers that are subsequently treated as valid kernel object structures by privileged driver code.
The operational impact of this flaw is severe, resulting in a complete breakdown of the CONFIG_USERSPACE isolation boundary. When the vulnerable path is executed on affected drivers such as i2s_litex.c, which does not special-case the unconfigure operation to discard user-supplied configuration data, the kernel proceeds to copy the attacker-controlled struct i2s_config into internal stream structures. Subsequently, when an application triggers audio playback or recording via i2s_trigger with I2S_TRIGGER_START, the driver enables FIFO interrupts and invokes interrupt handlers such as i2s_litex_isr_rx or i2s_litex_isr_tx. These handlers execute in supervisor context and call k_mem_slab_alloc and k_mem_slab_free using the unvalidated pointer provided by user space. This results in an arbitrary kernel memory read-write primitive, allowing attackers to manipulate critical kernel data structures including spinlocks and free lists associated with memory slabs.
This vulnerability aligns with CWE-20 Improper Input Validation as the system fails to adequately validate input parameters before processing them within a privileged context. Furthermore, it represents a significant breach of security boundaries consistent with ATT&CK technique T1548 Abuse Elevation Control Mechanism, where an attacker exploits flawed logic in access control mechanisms to escalate privileges from user mode to kernel mode. The exploitability is heightened by the fact that any thread possessing access rights to an I2S device object can trigger this condition with a single API call, making it accessible to potentially low-privilege applications within a multi-process environment.
The root cause lies in the asymmetry of validation between configuration and unconfiguration paths. While standard drivers often ignore user-supplied data during unconfigure operations, specific implementations like i2s_litex retain this data for logging or state management purposes without verifying its integrity. This creates an attack surface where malicious actors can craft a config structure containing pointers to attacker-controlled memory regions. Once the kernel dereferences these pointers in interrupt context, it gains arbitrary read and write capabilities relative to physical memory addresses, potentially leading to full system compromise, denial of service through kernel panic, or stealthy persistence mechanisms if the attacker modifies critical security structures.
Mitigation strategies must address both immediate code fixes and broader architectural improvements. The primary remediation involves modifying z_vrfy_i2s_configure to explicitly zero out config.mem_slab and config.block_size fields when handling unconfigure requests. This ensures that even if a driver attempts to use these values, it receives null or safe defaults rather than arbitrary user-supplied pointers. Additionally, developers should audit all in-tree and out-of-tree I2S drivers to ensure they do not rely on user-supplied configuration data during stream teardown operations. Implementing stricter input validation policies across all syscall handlers that interact with kernel objects is essential to prevent similar bypasses in other subsystems. Regular security audits focusing on the separation of privilege levels between user-space applications and kernel-mode device drivers will further reduce the risk of elevation-of-privilege vulnerabilities arising from improper state management during resource deallocation phases.