{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-35843",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-35843"
  ],
  "published": "2024-05-17T14:40:27Z",
  "summary": "iommu/vt-d: Use device rbtree in iopf reporting path",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Use device rbtree in iopf reporting path\n\nThe existing I/O page fault handler currently locates the PCI device by\ncalling pci_get_domain_bus_and_slot(). This function searches the list\nof all PCI devices until the desired device is found. To improve lookup\nefficiency, replace it with device_rbtree_find() to search the device\nwithin the probed device rbtree.\n\nThe I/O page fault is initiated by the device, which does not have any\nsynchronization mechanism with the software to ensure that the device\nstays in the probed device tree. Theoretically, a device could be released\nby the IOMMU subsystem after device_rbtree_find() and before\niopf_get_dev_fault_param(), which would cause a use-after-free problem.\n\nAdd a mutex to synchronize the I/O page fault reporting path and the IOMMU\nrelease device path. This lock doesn't introduce any performance overhead,\nas the conflict between I/O page fault reporting and device releasing is\nvery rare.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/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-2024-35843"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:52:36Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 8.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerable `prq_event_thread()` is driven by device-generated PCIe Page Requests, which local software can produce on demand through an SVA-capable accelerator work queue, a DRM render node, or a PRI-capable device assigned to a guest via VFIO/IOMMUFD. There is no network or physical-only requirement.\nAC:L - The attacker can flood the PRQ ring (even provoking PRQ overflow) to keep the racy window continuously executing and retry indefinitely, and in the assigned-device/malicious-endpoint case also controls the removal side via link-down, surprise-removal or AER-triggered teardown. The window is also structurally wide because `device_del()` frees `dev->iommu` before `pci_destroy_dev()` unlinks the device from the PCI bus list, so `pci_get_domain_bus_and_slot()` keeps returning a device whose `dev->iommu` is already freed.\nPR:L - Only access to a device that can emit page requests is needed \u2014 an SVA work queue or render node routinely granted to unprivileged users, or guest-side control of a passed-through device. No real root or CAP_SYS_ADMIN in the init namespace is required.\nUI:N - The page request is generated by the attacker-driven device and handled asynchronously in the IOMMU threaded IRQ handler; no victim action is involved.\nS:C - The VT-d driver is the authority that confines DMA-capable devices to their assigned address spaces, and here a device-initiated page request corrupts host kernel memory outside that confinement. In the passthrough deployment this is a guest/device-to-host escape across the IOMMU isolation boundary.\nC:H - The use-after-free reads `param->fault_param` and `fparam->data` out of a freed kmalloc-96/128 object that an unprivileged process can reallocate with sprayed content, turning the subsequent dereferences into an arbitrary kernel-memory read and disclosure primitive.\nI:H - `mutex_lock(&param->lock)` writes into the freed object, `list_add_tail(&evt_pending->list, &fparam->faults)` gives a write through an attacker-controlled pointer, and `fparam->handler(&evt->fault, fparam->data)` is an indirect call through a function pointer read from freed memory \u2014 a control-flow hijack primitive.\nA:H - Dereferencing the freed `dev_iommu` in the IOMMU threaded IRQ handler oopses or panics the kernel, and a corrupted mutex in that path can hang all subsequent page-fault handling."
    }
  }
}