FKIE_CVE-2026-12235

Vulnerability from fkie_nvd - Published: 2026-08-12 05:17 - Updated: 2026-11-04 05:18
Severity
6.3 (Medium) - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
Summary
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.
References
vulnerabilities@zephyrproject.orghttps://github.com/zephyrproject-rtos/zephyr/commit/106540afbd22087ad40b90f53fb22657754a719e
vulnerabilities@zephyrproject.orghttps://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xv9q-6mrf-8j49
134c704f-9b21-4f2e-91b3-4a467353bcc0https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xv9q-6mrf-8j49
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
          "defaultStatus": "unaffected",
          "packageName": "zephyr",
          "product": "zephyr",
          "programFiles": [
            "subsys/llext/llext_link.c"
          ],
          "vendor": "zephyrproject",
          "versions": [
            {
              "lessThan": "4.3.2",
              "status": "affected",
              "version": "3.7.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.4.2",
              "status": "affected",
              "version": "4.4.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "vulnerabilities@zephyrproject.org"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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\u0027s RELA table, so a crafted entry with an offset larger than the target section makes the write land arbitrarily far outside the extension\u0027s 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."
    },
    {
      "lang": "es",
      "value": "El subsistema Linkable Loadable Extensions (llext) maneja incorrectamente las entradas de reubicaci\u00f3n PLT/RELA al enlazar una extensi\u00f3n ELF reubicable (parcialmente enlazada). En llext_link_plt() (subsys/llext/llext_link.c), la rama reubicable (tgt != NULL, la ruta utilizada para objetos reubicables de Xtensa) calcul\u00f3 la direcci\u00f3n del parche como ext  -\u003e  mem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt  -\u003e  sh_offset y luego realiz\u00f3 la escritura de reubicaci\u00f3n all\u00ed sin validar rela.r_offset. Su rama hermana compartida/din\u00e1mica ya rechazaba offsets fuera de rango a trav\u00e9s de llext_file_offset().\n\nrela.r_offset se lee directamente de la tabla RELA del ELF, por lo que una entrada manipulada con un offset mayor que la secci\u00f3n objetivo hace que la escritura caiga arbitrariamente lejos fuera del b\u00fafer de texto de la extensi\u00f3n. El resultado es una escritura fuera de l\u00edmites influenciada por el atacante (la ubicaci\u00f3n a trav\u00e9s de r_offset, el valor escrito siendo la direcci\u00f3n del s\u00edmbolo resuelto) realizada en contexto de supervisor en tiempo de enlace, antes de que se ejecute cualquier c\u00f3digo de la extensi\u00f3n.\n\nLa ruta se alcanza desde llext_load() siempre que una aplicaci\u00f3n carga una extensi\u00f3n ELF influenciada por el atacante en Xtensa con almacenamiento escribible; llext est\u00e1 documentado para aceptar extensiones de origen no confiable. El impacto es corrupci\u00f3n de memoria en contexto de supervisor (p\u00e9rdida de integridad y disponibilidad, y un escape del l\u00edmite de la sandbox para extensiones en modo usuario). La explotaci\u00f3n est\u00e1 limitada por la ruta PLT reubicable de Xtensa y el almacenamiento escribible, y convertir la escritura fuera de rango en una primitiva \u00fatil no es trivial.\n\nLa soluci\u00f3n a\u00f1ade una comprobaci\u00f3n de l\u00edmites que rechaza cualquier entrada RELA cuyo r_offset \u003e= tgt  -\u003e  sh_size, reflejando la validaci\u00f3n existente en la rama compartida."
    }
  ],
  "id": "CVE-2026-12235",
  "lastModified": "2026-11-04T05:18:38.317",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 6.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.0,
        "impactScore": 5.2,
        "source": "vulnerabilities@zephyrproject.org",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-12235",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-12T12:34:31.991332Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-12T05:17:42.277",
  "references": [
    {
      "source": "vulnerabilities@zephyrproject.org",
      "url": "https://github.com/zephyrproject-rtos/zephyr/commit/106540afbd22087ad40b90f53fb22657754a719e"
    },
    {
      "source": "vulnerabilities@zephyrproject.org",
      "url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xv9q-6mrf-8j49"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-xv9q-6mrf-8j49"
    }
  ],
  "sourceIdentifier": "vulnerabilities@zephyrproject.org",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-787"
        }
      ],
      "source": "vulnerabilities@zephyrproject.org",
      "type": "Secondary"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.