Re: [BUG] iommu: KASAN slab-use-after-free in iommufd_auto_response_faults

[Ankit Soni]

On Tue, Jul 07, 2026 at 06:36:40PM +0800, Peiyang He wrote:
> > The analysis above goes through the iommufd selftest mock device (M). We
> > have not reproduced this on real Intel/AMD hardware, but the same lifetime
> > issue is not specific to the mock driver: Intel and AMD both have real detach
> > paths that can reach the very same iopf_queue_remove_device(). This is exactly
> > what iommufd_hwpt_detach_device() triggers, via iommu_detach_group_handle() /
> > iommu_detach_device_pasid(), right before it calls iommufd_auto_response_faults().
> > 

../..

> > AMD (drivers/iommu/amd/): the evidence here only covers the RID/group-detach
> > path.
> >   blocked_domain_attach_device()     [attach_dev, RID]       iommu.c:2883
> >   --> detach_device()                                        iommu.c:2398
> >   --> amd_iommu_iopf_remove_device()                         ppr.c:270
> >   --> iopf_queue_remove_device()                             ppr.c:273
> > AMD's PASID path, blocked_domain_set_dev_pasid() (iommu.c:2900), only calls
> > amd_iommu_remove_dev_pasid() and does not reach iopf_queue_remove_device().
> 
> Hello Linux kernel developers and maintainers,
> 
> After further analysis of the code, we think that this UAF should not be feasible on AMD devices,
> but still feasible on Intel devices.
> 
> ===
> AMD
> ===
> 
> We found no path by which a real AMD PPR fault can land in an IOMMUFD hw_pagetable's
> fault->common.deliver or fault->response.
> 
> A real AMD PPR fault is always PASID-valid: iommu_call_iopf_notifier(), the only
> iommu_report_device_fault() call site under drivers/iommu/amd/, rejects PASID 0 and always sets
> IOMMU_FAULT_PAGE_REQUEST_PASID_VALID (drivers/iommu/amd/ppr.c:107,140-148).
> 
> find_fault_handler() (drivers/iommu/io-pgfault.c:118) resolves a PASID-valid fault only via a
> per-PASID attach_handle, or a fallback to a RID-level NESTED domain gated by ops->user_pasid_table.
> AMD does not set that flag (only arm-smmu-v3.c:4389 and the iommufd selftest mock, selftest.c:861,
> do), so a failed per-PASID lookup is simply aborted on AMD, never delivered to any RID-level domain.
> 
> The per-PASID lookup cannot succeed toward an IOMMUFD HWPT on AMD, because the
> AMD domains that IOMMUFD can allocate as HWPTs do not implement .set_dev_pasid:
> amdv1_ops (iommu.c:2663), amdv2_ops (iommu.c:2741), and nested_domain_ops
> (drivers/iommu/amd/nested.c:291) all lack it. Therefore, if userspace tries to
> attach one of those IOMMUFD HWPT domains to a PASID, iommu_attach_device_pasid()
> rejects it with -EOPNOTSUPP at the !domain->ops->set_dev_pasid check
> (drivers/iommu/iommu.c:3625,3641-3644). The AMD nested RID attach path is not a
> substitute here either: nested_attach_device() refuses attachment when PASID is
> enabled (WARN_ON(dev_data->pasid_enabled), nested.c:244).
> 
> AMD does have a domain with .set_dev_pasid, amd_sva_domain_ops
> (drivers/iommu/amd/pasid.c:177), but that is the kernel SVA domain path, not an
> IOMMUFD HWPT. The SVA allocation path installs iommu_sva_iopf_handler()
> (drivers/iommu/iommu-sva.c:298,327), not iommufd_fault_iopf_handler(), so faults
> delivered there are not linked into an iommufd_fault object's deliver/response
> queues.
> 

Hi,

Your analysis is correct. Currently AMD is not affected by this bug.

The UAF requires iommufd_fault_iopf_handler to be registered as the
IOPF handler for the device, which only happens when an iopf-capable
HWPT is attached via a domain with .set_dev_pasid implemented.
AMD's IOMMUFD HWPT domain ops (amd_iommu_domain_ops) do not implement
.set_dev_pasid, so iommufd_fault_iopf_handler is never installed for
AMD. The PASID-less path through mock_domain_nop_attach is also not
reachable via the IOMMUFD fault path.

The existing _test_cmd_trigger_iopf() helper always responds immediately 
(read+write on fault_fd), which is why the current selftest  does not 
catch this.

@Jason,
Is it worth adding a test variant that triggers an IOPF without
responding and then detaches — to cover the cleanup path in
iommufd_auto_response_faults() as a regression test?

-Ankit