BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_vblanks()

[Dmitry Osipenko]

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 ]------------