CVE-2023-53795

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: IOMMUFD_DESTROY should not increase the refcount<br /> <br /> syzkaller found a race where IOMMUFD_DESTROY increments the refcount:<br /> <br /> obj = iommufd_get_object(ucmd-&gt;ictx, cmd-&gt;id, IOMMUFD_OBJ_ANY);<br /> if (IS_ERR(obj))<br /> return PTR_ERR(obj);<br /> iommufd_ref_to_users(obj);<br /> /* See iommufd_ref_to_users() */<br /> if (!iommufd_object_destroy_user(ucmd-&gt;ictx, obj))<br /> <br /> As part of the sequence to join the two existing primitives together.<br /> <br /> Allowing the refcount the be elevated without holding the destroy_rwsem<br /> violates the assumption that all temporary refcount elevations are<br /> protected by destroy_rwsem. Racing IOMMUFD_DESTROY with<br /> iommufd_object_destroy_user() will cause spurious failures:<br /> <br /> WARNING: CPU: 0 PID: 3076 at drivers/iommu/iommufd/device.c:477 iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:478<br /> Modules linked in:<br /> CPU: 0 PID: 3076 Comm: syz-executor.0 Not tainted 6.3.0-rc1-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023<br /> RIP: 0010:iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:477<br /> Code: e8 3d 4e 00 00 84 c0 74 01 c3 0f 0b c3 0f 1f 44 00 00 f3 0f 1e fa 48 89 fe 48 8b bf a8 00 00 00 e8 1d 4e 00 00 84 c0 74 01 c3 0b c3 0f 1f 44 00 00 41 57 41 56 41 55 4c 8d ae d0 00 00 00 41<br /> RSP: 0018:ffffc90003067e08 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888109ea0300 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000ffffffff<br /> RBP: 0000000000000004 R08: 0000000000000000 R09: ffff88810bbb3500<br /> R10: ffff88810bbb3e48 R11: 0000000000000000 R12: ffffc90003067e88<br /> R13: ffffc90003067ea8 R14: ffff888101249800 R15: 00000000fffffffe<br /> FS: 00007ff7254fe6c0(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555557262da8 CR3: 000000010a6fd000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> iommufd_test_create_access drivers/iommu/iommufd/selftest.c:596 [inline]<br /> iommufd_test+0x71c/0xcf0 drivers/iommu/iommufd/selftest.c:813<br /> iommufd_fops_ioctl+0x10f/0x1b0 drivers/iommu/iommufd/main.c:337<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x84/0xc0 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x38/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The solution is to not increment the refcount on the IOMMUFD_DESTROY path<br /> at all. Instead use the xa_lock to serialize everything. The refcount<br /> check == 1 and xa_erase can be done under a single critical region. This<br /> avoids the need for any refcount incrementing.<br /> <br /> It has the downside that if userspace races destroy with other operations<br /> it will get an EBUSY instead of waiting, but this is kind of racing is<br /> already dangerous.