CVE-2026-12235

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-&gt;mem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt-&gt;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().<br /> <br /> rela.r_offset is read directly from the ELF&amp;#39;s RELA table, so a crafted entry with an offset larger than the target section makes the write land arbitrarily far outside the extension&amp;#39;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.<br /> <br /> 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.<br /> <br /> The fix adds a bound check rejecting any RELA entry whose r_offset &gt;= tgt-&gt;sh_size, mirroring the existing validation in the shared branch.