Lu Baolu

A memory leak issue has been identified in the Linux kernel, specifically in the iopf queue remove device() function. This function is responsible for removing a device from the per-iommu iopf queue when PRI is disabled on the device. However, it fails to release the group structure that represents a group of iopf's awaiting a response after responding to the hardware, potentially causing a memory leak if iopf queue remove device() is called with pending iopf's.

A NULL pointer dereference issue has been resolved in the Linux kernel's iommu/vt-d component. The issue occurs when trying to map pages to a nested parent domain, resulting in a NULL dereference. Additionally, there is a potential memory leak due to the lack of a lock around the domain->qi batch allocation. The issue is fixed by adding a helper for qi batch allocation and calling it in both the cache tag assign domain() and cache tag assign parent domain() functions.

The issue arises from the current implementation of the Linux kernel, where cache tags are removed after disabling ATS, leading to potential memory leaks and kernel crashes. Specifically, CACHE TAG DEVTLB type cache tags may remain in the list even after the domain is freed, causing a use-after-free condition. This problem occurs when multiple VFs from different PFs are passed through to a single user-space process via vfio-pci, resulting in kernel crashes with messages like "BUG: kernel NULL pointer dereference". The `cache tag flush range` function is involved in the issue, and moving `cache tag unassign domain` before `iommu disable pci caps` can fix it.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to a potential memory leak in the `intel setup irq remapping()` function. This leak occurs when the `fn` is only freed after failing to allocate `ir domain`, but it should also be freed in case `dmar enable qi` returns an error. Additionally, `irq domain` and `ir msi domain` need to be removed if `intel setup irq remapping` fails to enable queued invalidation. The rewinding path has been improved by adding `out free ir domain` and `out free fwnode` labels. This issue can potentially allow an attacker to cause a denial of service. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

The issue is related to the `iommu sva bind device()` function, which should return either a sva bond handle or an `ERR PTR` value in error cases. However, existing drivers, such as `idxd` and `uacce`, only check the return value with `IS ERR()`, potentially leading to a kernel NULL pointer dereference issue if the function returns `NULL` instead of an error pointer. In reality, this doesn't cause any problems because `iommu sva bind device()` only returns `NULL` when the kernel is not configured with `CONFIG IOMMU SVA`, and in this case, `iommu dev enable feature(dev, IOMMU DEV FEAT SVA)` will return an error, preventing the device drivers from calling `iommu sva bind device()`.

The issue is related to the I/O page fault handler in the Linux kernel, which currently locates the PCI device by calling `pci get domain bus and slot()`. This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, it is replaced with `device rbtree find()` to search the device within the probed device rbtree. The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after `device rbtree find()` and before `iopf get dev fault param()`, which would cause a use-after-free problem. A mutex is added to synchronize the I/O page fault reporting path and the IOMMU release device path.

A sysfs leak in the `alloc iommu()` function has been resolved. The `iommu device sysfs add()` function is called before, and it has to be cleaned on subsequent errors.