{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-89452",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-89452"
  ],
  "published": "2026-09-11T19:47:07Z",
  "summary": "iommu/msm: Unwind probe state on registration failure",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/msm: Unwind probe state on registration failure\n\nmsm_iommu_probe() adds its devm-managed IOMMU object to\nqcom_iommu_devices before adding the IOMMU sysfs device and registering\nit with the IOMMU core.\n\nIf iommu_device_sysfs_add() fails, probe returns with the object still on\nqcom_iommu_devices. The driver core then releases the devm allocation,\nleaving a dangling list entry that later list walks may dereference.\n\nIf iommu_device_register() fails, the same dangling list entry remains\nand the sysfs device is left registered as well.\n\nUnwind the sysfs device and global list entry in reverse setup order on\nthe corresponding failure paths.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": null,
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89452"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/51e37f9179387b6e3fa64a3d3b4fece1a38b3a02"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/f532401be9312ecd166f616bb74a65b0b4c150fa"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/7f7074a886c4a93e3d12076ce60a510a1ebe400c"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/535a200220ca2c83bc8bf54bd2cbe045d6ee70c4"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-10-03T11:04:09Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 8.4,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The bug is in msm_iommu_probe() for the Qualcomm APQ8064 platform IOMMU (compatible qcom,apq8064-iommu). It is reached only through the local platform driver core at boot or sysfs bind, not via network protocols, Bluetooth/WiFi, or a physical USB/serial endpoint.\nAC:L - After list_add, a failed iommu_device_sysfs_add() or iommu_device_register() deterministically leaves a freed msm_iommu_dev on qcom_iommu_devices. APQ8064 has four IOMMU instances, so a later probe, of_xlate, or attach walks that list and dereferences the object with no attacker-uncontrolled race. GFP_ATOMIC allocation in insert_iommu_master during register can induce the failure.\nPR:N - msm_iommu_probe() and later list walks in qcom_iommu_of_xlate(), find_iommu_for_dev(), and msm_iommu_attach_dev() run from the platform/IOMMU core with no capable() or credential check. On APQ8064 phones and embedded boards this happens automatically during boot or deferred probe without a user account.\nUI:N - Platform probe and subsequent IOMMU client attach/xlate run unattended during normal kernel device bring-up. No victim action such as mounting a filesystem, opening a file, or clicking a prompt is required.\nS:U - The use-after-free corrupts host kernel heap through the driver's private qcom_iommu_devices list, enabling in-kernel privilege escalation. It does not by itself escape a VM or bypass the IOMMU/DMA isolation boundary as a distinct security authority.\nC:H - The dangling msm_iommu_dev stays linked after devm frees it. Subsequent list walks dereference attacker-influencable freed heap (including embedded list pointers and device state), which per kernel UAF guidance enables arbitrary kernel memory disclosure.\nI:H - Use-after-free of the IOMMU instance structure (list nodes, MMIO base, context-bank maps) allows heap spraying and hijack of later attach/xlate control flow, providing an arbitrary kernel write and code-execution primitive.\nA:H - Any later walk of qcom_iommu_devices after the failed probe dereferences freed memory and can oops or panic the kernel. Kernel UAFs also crash even when not turned into a full exploit."
    }
  }
}