Re: [BUG] iommufd/selftest: KASAN slab-use-after-free in iommu_report_device_fault
Jason Gunthorpe <[email protected]>
| Newsgroups | dev.linux.lists.iommu,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Jul 28, 2026 at 01:32:09PM +0800, Peiyang He wrote: > On 2026/7/27 17:41, Tian, Kevin wrote: > >> From: Peiyang He <[email protected]> > >> Sent: Wednesday, July 22, 2026 5:52 PM > >> > > [...] > > > Since iommu_attach_handle_get() explicitly says that the caller should be > >> responsible for "synchronize the call of iommu_attach_handle_get() > >> with domain attachment and detachment", maybe we shouldn't add extra > >> lifetime > >> management mechanism around iommu_attach_handle, instead we should > >> fix this at the caller side. > >> > >> Fault report can run concurrently with PASID detach and replacement, but > >> before the old attach handle is removed and freed, mockdev must block new > >> reports > >> for that PASID and wait for in-flight iommu_report_device_fault() calls to > >> finish. > >> > > > > yes the mock driver should drain in-flight fault requests before the > > actual detachment, just like other iommu drivers do. > > Hi Kevin, > > Thanks for your reply. I looked into the code in more detail. Would this > approach make sense? > > In iommufd_test_trigger_iopf(), call iommu_report_device_fault() under the protection > of idev->igroup->lock. Since detach and replace also require the same lock, they can > be serialized with fault reporting. This would ensure that a mock fault report either > completes before detach/replace starts, or starts only after the old handle has been removed. > Thus it should prevent the UAF. > > Would this simple serialization meet the design intention of mock dev? Or would you prefer > an explicit quiesce/drain mechanism instead? The mock driver should follow the expected design of a real driver, so I'd put an internal rwsem or something like that to protect this Jason