https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 16 Oct 2026 10:34:40 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-351397 EUVD-2026-351397 https://cve.radiocsirt.org/vuln/euvd-2026-351397 https://cve.radiocsirt.org/vuln/fkie_cve-2026-12235 <p>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().</p> <p>rela.r_offset is read directly from the ELF&#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&#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.</p> <p>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.</p> <p>The fix adds a bound chec…</p> <p>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().</p> <p>rela.r_offset is read directly from the ELF&#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&#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.</p> <p>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.</p> <p>The fix adds a bound chec…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-12235