Re: [PATCH] iommu/iommufd: Fix NULL pointer deref in iommufd_ioas_change_process when racing with iopt_map_file_pages

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Aug 12, 2026 at 12:35:04PM +0800, Peiyang He wrote:
> On 2026/8/11 03:59, Jason Gunthorpe wrote:
> >> @@ -535,6 +535,10 @@ int iommufd_ioas_change_process(struct iommufd_ucmd *ucmd)
> >>  		return rc;
> >>  
> >>  	for_each_ioas_area(&ioas_list, index, ioas, area)  {
> >> +		if (!area->pages) {
> >> +			rc = -EBUSY;
> >> +			goto out;
> >> +		}
> >>  		if (area->pages->type != IOPT_ADDRESS_FILE) {
> >>  			rc = -EINVAL;
> >>  			goto out;
> > 
> > If we do this then a concurrent map will get corrupted accounting. I think we
> 
> From my understanding, if iommufd_ioas_change_process() returns with EBUSY when
> detecting a NULL area->pages, later accounting logic in iommufd_ioas_change_process()
> won't be executed. I may be missing something, feel free to point it
> out.

The map side will be racing and it has already partially setup some of
its accounting, but I guess you are saying since the change process
aborts that is OK?

> Taking domains_rwsem in iommufd_take_all_iova_rwsem() alone may not prevent the NULL pointer deref.
> For example:
>     change_process: take domains_rwsem for write
>     map:            take iova_rwsem for write, insert an area with area->pages == NULL, and release iova_rwsem
>     map:            try to take domains_rwsem for read and block
>     change_process: take iova_rwsem for write and iterate the area


Yes, I guess it does unlock as it runs too bad

So this patch is probably the best option

Jason