CVE-2026-12235: zephyrproject zephyr · Bounds
Affects zephyrproject zephyrSource CVE Database V5
Not known to be exploited · CVSS 6.3 Medium : upgrade to 4.4.2 or 4.3.2 when convenient.
Data as of 9 Nov 2026, 11:38 UTC
Thin evidence
One scorer or none| CNA (zephyr) | CVSS 3.1 | 6.3 |
|---|
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 4.4.2, 4.3.2
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 12 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 9 Nov 2026.
What to do
Upgrade zephyrproject zephyr to 4.4.2 or 4.3.2.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| zephyrprojectzephyr | Affected
| Fixed in
|
| zephyrprojectzephyr | Affected
| Fixed in
|
GitHubzephyrpkg:github/zephyrOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
The described fix adds bounds checking on relocation offsets to prevent out-of-bounds writes. If you cannot patch yet, avoid loading untrusted relocatable ELF extensions on Xtensa architectures with writable storage to mitigate risk.
Description
The Linkable Loadable Extensions (llext) subsystem mis-handles PLT/RELA relocation entries when linking a relocatable (partially-linked) ELF extension. In llext_link_plt() (subsys/llext/llext_link.c), the relocatable branch (tgt != NULL, the path used for Xtensa relocatable objects) computed the patch address as ext->mem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt->sh_offset and then performed the relocation write there without validating rela.r_offset. Its sibling shared/dynamic branch already rejected out-of-range offsets via llext_file_offset(). rela.r_offset is read directly from the ELF's RELA table, so a crafted entry with an offset larger than the target section makes the write land arbitrarily far outside the extension's text buffer. The result is an attacker-influenced out-of-bounds write (the location via r_offset, the written value being the resolved symbol address) performed in supervisor context at link time, before any extension code runs. The path is reached from llext_load() whenever an application loads an attacker-influenced ELF extension on Xtensa with writable storage; llext is documented to accept extensions of untrusted origin. Impact is supervisor-context memory corruption (integrity and availability loss, and a sandbox-boundary escape for user-mode extensions). Exploitation is gated by the Xtensa relocatable PLT path and writable storage, and turning the out-of-range write into a useful primitive is non-trivial. The fix adds a bound check rejecting any RELA entry whose r_offset >= tgt->sh_size, mirroring the existing validation in the shared branch.