{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2024-35843","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2024-05-17T13:50:33.104Z","datePublished":"2024-05-17T14:40:10.747Z","dateUpdated":"2026-08-05T11:30:15.505Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-05T11:30:15.505Z"},"descriptions":[{"lang":"en","value":"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."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","baseScore":8.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"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 — 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 — 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."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/iommu/intel/dmar.c","drivers/iommu/intel/iommu.c","drivers/iommu/intel/iommu.h","drivers/iommu/intel/svm.c"],"versions":[{"version":"06f4b8d09dbabec631ed7b033f5d5413d86c7134","lessThan":"3d39238991e745c5df85785604f037f35d9d1b15","status":"affected","versionType":"git"},{"version":"06f4b8d09dbabec631ed7b033f5d5413d86c7134","lessThan":"def054b01a867822254e1dda13d587f5c7a99e2a","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/iommu/intel/dmar.c","drivers/iommu/intel/iommu.c","drivers/iommu/intel/iommu.h","drivers/iommu/intel/svm.c"],"versions":[{"version":"6.1","status":"affected"},{"version":"0","lessThan":"6.1","status":"unaffected","versionType":"semver"},{"version":"6.8.2","lessThanOrEqual":"6.8.*","status":"unaffected","versionType":"semver"},{"version":"6.9","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.1","versionEndExcluding":"6.8.2"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.1","versionEndExcluding":"6.9"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15"},{"url":"https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a"}],"title":"iommu/vt-d: Use device rbtree in iopf reporting path","x_generator":{"engine":"bippy-1.2.0"}},"adp":[{"problemTypes":[{"descriptions":[{"type":"CWE","cweId":"CWE-416","lang":"en","description":"CWE-416 Use After Free"}]}],"affected":[{"vendor":"linux","product":"linux_kernel","cpes":["cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"],"defaultStatus":"unknown","versions":[{"version":"1da177e4c3f4","status":"affected","lessThan":"3d39238991e7","versionType":"custom"}]},{"vendor":"linux","product":"linux_kernel","cpes":["cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"],"defaultStatus":"unknown","versions":[{"version":"1da177e4c3f4","status":"affected","lessThan":"def054b01a86","versionType":"custom"}]},{"vendor":"linux","product":"linux_kernel","cpes":["cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"],"defaultStatus":"unknown","versions":[{"version":"6.8.2","status":"unaffected","lessThanOrEqual":"6.8.*","versionType":"custom"}]},{"vendor":"linux","product":"linux_kernel","cpes":["cpe:2.3:o:linux:linux_kernel:-:*:*:*:*:*:*:*"],"defaultStatus":"unknown","versions":[{"version":"6.9","status":"unaffected"}]}],"metrics":[{"cvssV3_1":{"scope":"UNCHANGED","version":"3.1","baseScore":6.8,"attackVector":"LOCAL","baseSeverity":"MEDIUM","vectorString":"CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","integrityImpact":"NONE","userInteraction":"NONE","attackComplexity":"LOW","availabilityImpact":"HIGH","privilegesRequired":"NONE","confidentialityImpact":"LOW"}},{"other":{"type":"ssvc","content":{"timestamp":"2024-06-04T19:36:46.083168Z","id":"CVE-2024-35843","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}}],"title":"ADP Container","providerMetadata":{"orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP","dateUpdated":"2024-06-04T19:36:51.450Z"}},{"providerMetadata":{"orgId":"af854a3a-2127-422b-91ae-364da2661108","shortName":"CVE","dateUpdated":"2024-08-02T03:21:49.021Z"},"title":"CVE Program Container","references":[{"url":"https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15","tags":["x_transferred"]},{"url":"https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a","tags":["x_transferred"]}]}]}}