Re: [BUG] iommufd/selftest: KASAN slab-use-after-free in iommu_report_device_fault

[Peiyang He]

On 2026/8/11 04:02, Jason Gunthorpe wrote:
> 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 <peiyang_he@xxxxxxxxxxxxxxxx>
>>>> 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
> 

Thanks for this suggestion! PTAL at https://lore.kernel.org/all/38C8DF0A118B7176+20260811095551.2756745-1-peiyang_he@xxxxxxxxxxxxxxxx/

Best regards,
Peiyang