CVE-2024-35843

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

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.

AC:LAttack complexity, low

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.

PR:LPrivileges required, low

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.

UI:NUser interaction, none

The page request is generated by the attacker-driven device and handled asynchronously in the IOMMU threaded IRQ handler; no victim action is involved.

S:CScope, changed

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.

C:HConfidentiality impact, high

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.

I:HIntegrity impact, high

`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.

A:HAvailability impact, high

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.