Jason Gunthorpe

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.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to the `iommufd access change ioas()` function in the Linux kernel, which sets `access->ioas` to NULL during its process, potentially causing a lock to be gone in a concurrent racing context. This can lead to a general protection fault, probably for a non-canonical address. The problem is fixed by doing the same `access->ioas` sanity check as the `iommufd access rw()` and `iommufd access pin pages()` functions. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

The issue is related to an overwrite of `access->iopt access list id` in the `iopt add access()` function, which is called from `iommufd access change ioas()` when `xa alloc()` succeeds but `iopt calculate iova alignment()` fails. This results in a mismatch between the access pointer in the list and the passed-in pointer. The vulnerability can lead to a denial of service.

A NULL pointer dereference issue has been identified in the Linux kernel, specifically in the iommu/omap component. This issue arose from a regression caused by a commit that changed the function return type but missed converting one place, leading to the omap iommu probe returning 0 instead of ERR PTR(-ENODEV). The issue is triggered in the ` iommu probe device` function, which is called from `probe iommu group`, and subsequently from other functions such as `bus for each dev` and `bus iommu probe`. This problem was noted by Jason Gunthorpe and is associated with earlier commits that altered the iommu/omap probe functionality.

The issue allows remote attackers to cause a denial of service, resulting in a NULL pointer dereference and OOPS, when SCTP authentication is enabled. This occurs by starting to establish an association between two endpoints immediately after an exchange of INIT and INIT ACK chunks to establish an earlier association between these endpoints in the opposite direction.