{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2023-54026",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2023-54026"
  ],
  "published": "2025-12-24T10:57:20Z",
  "summary": "opp: Fix use-after-free in lazy_opp_tables after probe deferral",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nopp: Fix use-after-free in lazy_opp_tables after probe deferral\n\nWhen dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns\n-EPROBE_DEFER, the opp_table is freed again, to wait until all the\ninterconnect paths are available.\n\nHowever, if the OPP table is using required-opps then it may already\nhave been added to the global lazy_opp_tables list. The error path\ndoes not remove the opp_table from the list again.\n\nThis can cause crashes later when the provider of the required-opps\nis added, since we will iterate over OPP tables that have already been\nfreed. E.g.:\n\n  Unable to handle kernel NULL pointer dereference when read\n  CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3\n  PC is at _of_add_opp_table_v2 (include/linux/of.h:949\n  drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404\n  drivers/opp/of.c:1032) -> lazy_link_required_opp_table()\n\nFix this by calling _of_clear_opp_table() to remove the opp_table from\nthe list and clear other allocated resources. While at it, also add the\nmissing mutex_destroy() calls in the error path.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.21-1+rpt1"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi1-rpi-v6",
            "binary_version": "1:6.1.21-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi1-rpi-v7",
            "binary_version": "1:6.1.21-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l",
            "binary_version": "1:6.1.21-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi1-rpi-v8",
            "binary_version": "1:6.1.21-1+rpt1"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.21-1+rpt1": {
            "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed",
            "upstream_version": "6.1.21",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.40"
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-54026"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/39a0e723d3502f6dc4c603f57ebe8dc7bcc4a4bc"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/76ab057de777723ec924654502d1a260ba7d7d54"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/c05e76d6b249e5254c31994eedd06dd3cc90dee0"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/b2a2ab039bd58f51355e33d7d3fc64605d7f870d"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:24:39Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerable path lies entirely in the OPP core's device-probe code (`_allocate_opp_table()`), reached only through in-kernel driver probe/bind on the local system; there is no network, adjacent-network, or physical-device data path into it.\nAC:L - On an affected DT platform the combination of a lazy `required-opps` link plus an interconnect `-EPROBE_DEFER` occurs deterministically during probe ordering, and the dangling list entry is then consumed unconditionally by the next `lazy_link_required_opp_table()` walk \u2014 no race must be won and no unpredictable memory layout is required to reach the freed object.\nPR:L - No authentication or capability check exists in the OPP core path itself; the free-and-dangle happens in driver probe context, so a local low-privileged presence on the system is the most severity-favorable reading (the code performs no privilege validation of its own).\nUI:N - The dangling `lazy_opp_tables` entry is created and later dereferenced automatically as drivers probe and defer; no victim action such as opening a file or mounting a filesystem is needed.\nS:U - The corruption is confined to kernel heap objects owned by the OPP framework within the same kernel security authority \u2014 there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - `lazy_link_required_opp_table()` reads a freed `struct opp_table` \u2014 `np`, `required_opp_count`, `required_opp_tables[]`, `opp_list` \u2014 and follows those stale pointers, so reallocated slab contents can be read and leveraged for kernel memory disclosure, matching the UAF=High guidance.\nI:H - The same walk writes into the freed object: `required_opp_tables[i] = new_table`, the `set_required_opps` function-pointer field via `_update_set_required_opps()`, and a `list_del_init()` unlink through stale prev/next pointers \u2014 a classic write-what-where primitive plus function-pointer overwrite usable for control-flow hijack.\nA:H - The bug was reported as a kernel NULL-pointer dereference oops in `_of_add_opp_table_v2()`/`lazy_link_required_opp_table()` during boot, and any traversal of the freed table can panic the kernel or corrupt the global list."
    }
  }
}