Hi,
I was playing/testing SuperTuxKart using VirtIO-GPU driver and spotted a UAF bug in drm_atomic_helper_wait_for_vblanks().
SuperTuxKart can use DRM directly, i.e. you can run game in VT without Xorg or Wayland, this is where bugs happens. SuperTuxKart uses a non-blocking atomic page flips and UAF happens when a new atomic state is committed while there is a previous page flip still in-fly.
What happens is that the new and old atomic states refer to the same CRTC state somehow. Once the older atomic state is destroyed, the CRTC state is freed and the newer atomic state continues to use the freed CRTC state.
The bug is easily reproducible (at least by me) by playing SuperTuxKart for a minute. It presents on latest -next and 5.17-rc7, I haven't checked older kernel versions.
I'm not an expert of the non-blocking code paths in DRM, so asking for suggestions about where the root of the problem could be.
Here is the KASAN report:
================================================================== BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_vblanks.part.0+0x10b/0x4b0 Read of size 1 at addr ffff888110354809 by task kworker/u8:5/97
CPU: 1 PID: 97 Comm: kworker/u8:5 Not tainted 5.17.0-rc7-next-20220309+ #158 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound commit_work Call Trace: <TASK> dump_stack_lvl+0x49/0x5e print_report.cold+0x9c/0x562 ? drm_atomic_helper_wait_for_vblanks.part.0+0x10b/0x4b0 kasan_report+0xb9/0xf0 ? drm_atomic_helper_wait_for_vblanks.part.0+0x10b/0x4b0 __asan_load1+0x4d/0x50 drm_atomic_helper_wait_for_vblanks.part.0+0x10b/0x4b0 ? page_flip_common+0x150/0x150 ? complete_all+0x41/0x50 ? drm_atomic_helper_commit_hw_done+0x1a2/0x220 drm_atomic_helper_commit_tail+0x8c/0xa0 commit_tail+0x15c/0x1d0 commit_work+0x12/0x20 process_one_work+0x50e/0x9d0 ? pwq_dec_nr_in_flight+0x120/0x120 ? do_raw_spin_lock+0x10a/0x190 worker_thread+0x2ba/0x630 ? process_one_work+0x9d0/0x9d0 kthread+0x15d/0x190 ? kthread_complete_and_exit+0x30/0x30 ret_from_fork+0x1f/0x30 </TASK>
Allocated by task 325: kasan_save_stack+0x26/0x50 __kasan_kmalloc+0x88/0xa0 kmem_cache_alloc_trace+0x1fa/0x380 drm_atomic_helper_crtc_duplicate_state+0x4a/0x80 drm_atomic_get_crtc_state+0xbf/0x1d0 page_flip_common+0x46/0x150 drm_atomic_helper_page_flip+0x7a/0xe0 drm_mode_page_flip_ioctl+0x9c6/0xa20 drm_ioctl_kernel+0x145/0x220 drm_ioctl+0x34e/0x5f0 __x64_sys_ioctl+0xbe/0xf0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
Freed by task 230: kasan_save_stack+0x26/0x50 kasan_set_track+0x25/0x30 kasan_set_free_info+0x24/0x40 __kasan_slab_free+0x100/0x140 kfree+0xaf/0x310 drm_atomic_helper_crtc_destroy_state+0x1e/0x30 drm_atomic_state_default_clear+0x20e/0x5d0 __drm_atomic_state_free+0xbf/0x130 commit_tail+0x166/0x1d0 commit_work+0x12/0x20 process_one_work+0x50e/0x9d0 worker_thread+0x2ba/0x630 kthread+0x15d/0x190 ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff888110354800 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 9 bytes inside of 512-byte region [ffff888110354800, ffff888110354a00)
The buggy address belongs to the physical page: page:0000000010a164bd refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x110354 head:0000000010a164bd order:2 compound_mapcount:0 compound_pincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000001 ffff888100042c80 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888110354700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888110354780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888110354800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^ ffff888110354880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888110354900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== ------------[ cut here ]------------