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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-08-12T05:17:42.277Z",
  "pubdate": "2026-08-12T05:17:42.277Z",
  "executiveSummary": "The Linkable Loadable Extensions (llext) subsystem suffers from an out-of-bounds write vulnerability within its relocation handling logic. Specifically, the flaw exists in the llext_link_plt() function located in subsys/llext/llext_link.c, affecting Xtensa relocatable objects.\nThe vulnerability arises due to a missing bounds check on the r_offset field of ELF RELA relocation entries. Because llext is documented to accept extensions of untrusted origin, an attacker capable of providing a crafted ELF extension can supply a maliciously modified RELA table entry. When processed, this entry results in a patch address calculation that points arbitrarily outside the extension's text buffer, causing an out-of-bounds write of the resolved symbol address.\nThe impact of this flaw includes supervisor-context memory corruption, leading to integrity and availability loss, as well as a potential sandbox-boundary escape for user-mode extensions. Successful exploitation is constrained by prerequisites requiring the targeted system to utilize the Xtensa relocatable PLT path with writable storage, and the requirement for an attacker to supply a crafted ELF extension during the llext_load() process.",
  "technicalDetails": "The root cause of the vulnerability resides in the llext_link_plt() function inside subsys/llext/llext_link.c. When linking a relocatable (partially-linked) ELF extension—a code path specifically utilized by Xtensa relocatable objects where tgt != NULL—the subsystem computes the patch address using the formula: ext->mem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt->sh_offset.\nUnlike the sibling shared/dynamic branch of the function, which correctly validates offsets using llext_file_offset(), the relocatable branch performs the relocation write directly without validating that rela.r_offset falls within legitimate boundaries. Because rela.r_offset is read directly and without sanitization from the ELF's RELA table, a crafted entry containing an r_offset value larger than the target section causes the memory write operation to land arbitrarily far outside the designated extension text buffer.\nThe attack flow begins when an application invokes llext_load() to load an attacker-influenced ELF extension into the system. As the llext subsystem parses and links the object in supervisor context, it iterates over the RELA relocation entries. When the parser encounters the crafted relocation entry, the unvalidated r_offset manipulates the pointer arithmetic, turning the target write location into an arbitrary or semi-arbitrary memory address. The value written to this out-of-bounds location is the resolved symbol address.\nThis operation executes entirely in supervisor context at link time, prior to the execution of any extension code. Consequently, the memory corruption occurs immediately upon loading, bypassing runtime security checks and sandbox boundaries if user-mode extensions are in use. The exploitation primitive allows an attacker to overwrite adjacent supervisor memory structures, leading to system instability, control flow hijacking, or privilege escalation, contingent upon the exact memory layout and the values written."
}