Skip to main content
VulnerabilityPublished Updated

CVE-2026-12235: zephyrproject zephyr · Bounds

Affects zephyrproject zephyrSource CVE Database V5

0
Compare

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

CVSS 3.1 base score
6.3Medium
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (zephyr)CVSS 3.16.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:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 12 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
zephyrprojectzephyrAffected
  • >=4.4.0 <4.4.2
Fixed in
  • 4.4.2
zephyrprojectzephyrAffected
  • >=3.7.0 <4.3.2
Fixed in
  • 4.3.2
GitHubzephyrpkg:github/zephyrOther threatsAffected
  • >=3.7.0 <4.3.2
  • >=4.4.0 <4.4.2
Fixed in
  • 4.3.2
  • 4.4.2

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.

References

Community reviews

Loading reviews…