I2S configure syscall handler passes an unvalidated user-supplied kernel object pointer to drivers
Zephyr versions 4.4.0 up to 4.5.0 with CONFIG_USERSPACE, where a thread can reach an I2S device object, are exposed. The fix is in Zephyr 4.5.0. No vendor rating is given.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 4.5.0
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. Zephyr versions >= 4.4.0 and < 4.5.0 Requires CONFIG_USERSPACE and a thread with access to an I2S device object Driver must retain the caller's configuration on the unconfigure path, as drivers/i2s/i2s_litex.c does
- Exploitation?/40Exploitation: unknown (data gap). No CISA SSVC exploitation rating yet
- Exposure5/25Specific setups only
- Reach?/20Reach: unknown (data gap). No tracked technology or package matched
- Severity7.8/10CVSS 7.8
- No patch0/5No signal
What would change the score
- Would score about 63 if added to CISA KEV
- Would score about 58 if CISA's SSVC rates exploitation active
- Would score about 23 if CISA's SSVC rates it automatable
CVE-2026-87039 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 7.8 (high) and affects zephyr; fixed in 4.5.0.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- FIRST's estimate of the chance attackers exploit it in the next 30 days, updated daily.What do these mean? →
- 0.10% · 0th percentile
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 13/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 4.5.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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.
What to do
Check whether your setup matches what the bug needs.
Zephyr versions >= 4.4.0 and < 4.5.0 Requires CONFIG_USERSPACE and a thread with access to an I2S device object Driver must retain the caller's configuration on the unconfigure path, as drivers/i2s/i2s_litex.c doesUpgrade to a fixed version: 4.5.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- zephyr
From 4.4.0 · fixed in 4.5.0
Evidence 2
- Advisory
- Patch
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-87039
Is CVE-2026-87039 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
The I2S configure syscall handler passes a pointer from user space to drivers without validating it. This lets the kernel read and write memory at addresses the calling thread chooses, which breaks the isolation that CONFIG_USERSPACE provides.Source: github.com
Which versions are affected by CVE-2026-87039?
zephyr: from 4.4.0 before 4.5.0.Source: cve.now feed data
Am I affected, and how do I check?
Zephyr versions from 4.4.0 before 4.5.0. The bug needs CONFIG_USERSPACE and a thread with access to an I2S device object, and it applies to drivers that do not keep the caller's configuration on the unconfigure path, as the advisory describes for drivers/i2s/i2s_litex.c. To check, look at the Zephyr version in your tree and whether CONFIG_USERSPACE is set in your build configuration.Source: github.com
How do I fix CVE-2026-87039?
Upgrade to Zephyr 4.5.0 or later, which contains the fix. The sources give no workaround.Source: github.com