CVE-2026-12235 in Zephyr
Summary
by MITRE • 08/12/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/12/2026
The Linkable Loadable Extensions subsystem presents a critical vulnerability in its handling of Position Independent Executable relocation entries specifically affecting Xtensa architecture targets. This flaw exists within the llext_link_plt() function located in subsys/llext/llext_link.c where the system processes relocatable ELF extensions through a specialized code path for Xtensa objects. The vulnerability stems from an inadequate validation mechanism that fails to verify the bounds of relocation offsets when computing patch addresses for PLT/RELA entries during the linking process.
The technical implementation flaw manifests when the system computes a patch address using the formula ext->mem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt->sh_offset without performing proper validation on the rela.r_offset field. This field is directly sourced from the ELF's RELA table and can be manipulated by an attacker to contain values exceeding the legitimate bounds of the target section. The existing validation logic that already exists in the shared/dynamic branch through llext_file_offset() is absent in this relocatable branch, creating an exploitable inconsistency in the security model.
The operational impact of this vulnerability is severe as it enables an attacker-influenced out-of-bounds write operation performed in supervisor context during the link time phase before any extension code executes. This represents a fundamental violation of memory safety principles and creates opportunities for privilege escalation attacks. The attack vector requires an application to load an attacker-controlled ELF extension on Xtensa architecture systems with writable storage capabilities, which aligns with the documented security model that accepts extensions from untrusted sources.
The vulnerability maps directly to CWE-787 Out-of-bounds Write and CWE-121 Heap-based Buffer Overflow within the Common Weakness Enumeration framework, while also presenting characteristics consistent with ATT&CK technique T1059.001 Command and Scripting Interpreter and T1068 Exploitation for Privilege Escalation. The memory corruption occurs in supervisor context, potentially leading to complete system compromise through integrity and availability loss, along with sandbox boundary escapes for user-mode extensions.
The exploitation complexity involves multiple prerequisites including Xtensa architecture support, writable storage requirements, and the ability to craft malicious ELF extensions that trigger the specific relocatable PLT path. While turning this out-of-range write into a useful primitive requires significant effort, the supervisor context execution environment provides attackers with substantial leverage for privilege escalation attacks. The fix implements a straightforward bound check that ensures any RELA entry with r_offset greater than or equal to tgt->sh_size is rejected, effectively mirroring the validation already present in the shared branch and establishing consistent security boundaries across all code paths within the subsystem.
This vulnerability represents a critical security gap in kernel-level memory management for the Linux kernel's extension loading framework, particularly affecting systems that support Xtensa architecture and require robust security guarantees for untrusted extension handling. The mitigation approach of adding bounds checking aligns with established security practices for preventing buffer overflow vulnerabilities in kernel space code while maintaining compatibility with existing legitimate use cases.