{"id":"CVE-2026-12235","summary":"Out-of-bounds write in Xtensa llext PLT relocation from malformed ELF (CWE-787)","details":"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-\u003emem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt-\u003esh_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().\n\nrela.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.\n\nThe 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.\n\nThe fix adds a bound check rejecting any RELA entry whose r_offset \u003e= tgt-\u003esh_size, mirroring the existing validation in the shared branch.","aliases":["GHSA-xv9q-6mrf-8j49"],"modified":"2026-10-21T02:50:18.502977194Z","published":"2026-08-12T04:55:15.620Z","database_specific":{"cna_assigner":"zephyr","cwe_ids":["CWE-787"],"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/12xxx/CVE-2026-12235.json"},"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/12xxx/CVE-2026-12235.json"},{"type":"ADVISORY","url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xv9q-6mrf-8j49"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-12235"},{"type":"FIX","url":"https://github.com/zephyrproject-rtos/zephyr/commit/106540afbd22087ad40b90f53fb22657754a719e"},{"type":"PACKAGE","url":"https://github.com/zephyrproject-rtos/zephyr"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://github.com/zephyrproject-rtos/zephyr","events":[{"introduced":"36940db938a8f4a1e919496793ed439850a221c2"},{"fixed":"dccb09599635bdff17633fa7e9dab014b91dce90"},{"fixed":"106540afbd22087ad40b90f53fb22657754a719e"}],"database_specific":{"extracted_events":[{"range":[{"introduced":"3.7.0"},{"fixed":"4.4.2"}],"source":"AFFECTED_FIELD","strategy":"StandardRange"},{"range":[{"fixed":"106540afbd22087ad40b90f53fb22657754a719e"}],"source":"REFERENCES_COMMIT"}]}}],"versions":["v4.4.2-rc1","v4.4.1","v4.4.1-rc1","v4.4.0","v4.4.0-rc3","v4.4.0-rc2","v4.4.0-rc1","v4.3.0","v4.3.0-rc3","v4.3.0-rc2","v4.3.0-rc1","v4.2.0","v4.2.0-rc3","v4.2.0-rc2","v4.2.0-rc1","v4.1.0","v4.1.0-rc3","v4.1.0-rc2","v4.1.0-rc1","v4.0.0","v4.0.0-rc3","v4.0.0-rc2","v4.0.0-rc1","v3.7.0"],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-12235.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H"}]}