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.
Published: 2026-08-12
Score: 6.3 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The zephyrproject's Linkable Loadable Extensions subsystem incorrectly processes PLT/RELA relocation entries when linking a partially‑linked ELF extension for Xtensa. The calculation of the patch address uses an r_offset value from the ELF’s RELA table without validating that it lies within the bounds of the target section. A malformed entry with an offset beyond the target section results in a supervisor‑level out‑of‑bounds write located at whatever address the offset points to, and the written value is the resolved symbol address. This flaw is a classic out‑of‑bounds write (CWE‑787) that corrupts supervisor‑context memory and can potentially allow a sandbox‑bound user‑mode extension to escape its privilege boundary.

Affected Systems

The only explicit vendor/product listed is the Zephyr real‑time operating system. No specific version information is given in the advisory, so any build that includes the ll_ext subsystem on Xtensa processors and accepts loadable extensions of untrusted origin may be affected. The vulnerability is triggered only when an application loads an attacker‑influenced ELF extension on Xtensa platforms that provide writable storage for extensions.

Risk and Exploitability

The calibrated CVSS score of 6.3 indicates a moderate severity, and the EPSS score is not available, which does not allow an exact probability assessment. The vulnerability is not listed in the CISA KEV catalog, so there is no evidence of widespread exploitation. Exploitation requires the attacker to supply a crafted ELF extension that is loaded by an application, which is a high‑privilege operation that is typically restricted in production systems. Turning the out‑of‑range write into a reliable code‑execution primitive is described as non‑trivial, so the practical risk is limited to memory corruption and potential sandbox escape rather than immediate arbitrary code execution.

Generated by OpenCVE AI on August 12, 2026 at 12:48 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the Zephyr patch that introduces bounds checking for PLT/RELA relocations (commit 106540afbd22087ad40b90f53fb22657754a719e)
  • Rebuild and use a Zephyr release that contains the patched llext subsystem
  • Limit the use of writable storage for Xtensa loadable extensions or enforce trusted‑origin rules to prevent malicious extensions from being loaded
  • Verify the integrity of loadable extensions before passing them to llext_load (e.g., by code signing or checksum validation)

Generated by OpenCVE AI on August 12, 2026 at 12:48 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 12 Aug 2026 16:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Wed, 12 Aug 2026 13:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'poc', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Wed, 12 Aug 2026 05:00:00 +0000

Type Values Removed Values Added
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.
Title Out-of-bounds write in Xtensa llext PLT relocation from malformed ELF (CWE-787)
Weaknesses CWE-787
References
Metrics cvssV3_1

{'score': 6.3, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H'}


Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-08-12T12:34:55.518Z

Reserved: 2026-06-15T01:56:05.689Z

Link: CVE-2026-12235

cve-icon Vulnrichment

Updated: 2026-08-12T12:34:50.410Z

cve-icon NVD

Status : Received

Published: 2026-08-12T05:17:42.277

Modified: 2026-08-12T13:17:19.377

Link: CVE-2026-12235

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-12T16:30:05Z

Weaknesses