In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix protection fault in iommufdtestsyzconviova Syzkaller reported the following bug: general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] Call Trace: lockacquire lockacquire+0x1ce/0x4f0 downread+0x93/0x4a0 iommufdtestsyzconviova+0x56/0x1f0 iommufdtestaccessrw.isra.0+0x2ec/0x390 iommufdtest+0x1058/0x1e30 iommufdfopsioctl+0x381/0x510 vfsioctl _dosysioctl _sesysioctl _x64sysioctl+0x170/0x1e0 dosyscallx64 dosyscall64+0x71/0x140 This is because the new iommufdaccesschangeioas() sets access->ioas to NULL during its process, so the lock might be gone in a concurrent racing context. Fix this by doing the same access->ioas sanity as iommufdaccessrw() and iommufdaccesspin_pages() functions do.