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 dosyscall_64+0x71/0x140
This is because the new iommufdaccesschange_ioas() 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.