Re: [bug report] KVM: x86: Syzkaller has discovered an use-after-free issue in complete_emulated_mmio of kernel 5.10

[Sean Christopherson <seanjc@google.com>]

On Fri, Mar 14, 2025, zoudongjie wrote:
> Hi all,
> 
> I have discovered a use-after-free issue in complete_emulated_mmio during kernel fuzz testing
> with Syzkaller, the Call Trace is as follows:
> 
> Call Trace:
>  dump_stack+0xbe/0xfd
>  print_address_description.constprop.0+0x19/0x170
>  __kasan_report.cold+0x6c/0x84
>  kasan_report+0x3a/0x50
>  check_memory_region+0xfd/0x1f0
>  memcpy+0x20/0x60
>  complete_emulated_mmio+0x305/0x420
>  kvm_arch_vcpu_ioctl_run+0x63f/0x6d0
>  kvm_vcpu_ioctl+0x413/0xb20
>  __se_sys_ioctl+0x111/0x160
>  do_syscall_64+0x30/0x40
>  entry_SYSCALL_64_after_hwframe+0x67/0xd1
> 
> RIP: 0033:0x45570d
> Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f93213e9048 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 000000000058c1f0 RCX: 000000000045570d
> RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005
> RBP: 000000000058c1f0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 000000000000000b R14: 0000000000425750 R15: 00007fff27f167f0

Do you have the kernel Code + register state?  This is from the userspace ioctl().

> The buggy address belongs to the page:
> page:000000005de3ae57 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x111bff
> flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
> raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000
> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  ffff888111bff780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>  ffff888111bff800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >ffff888111bff880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>                                                  ^
>  ffff888111bff900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>  ffff888111bff980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> ==================================================================
> 
> Do you have any suggestions regarding this issue?

Do you have a reproducer?  A C reproducer in particular would be helpful.

And does this repro on the latest and great upstream?  It's possible the underlying
bug has been fixed, but not backported to v5.15 for whatever reason.

> Any insights or debugging strategies would be greatly appreciated.

Assuming the memcpy() is towards the end of complete_emulated_mmio() based on
the offsets, that would correspond to:

   memcpy(run->mmio.data, frag->data, min(8u, frag->len));

My guess would be that frag->data is bad/stale; run->mmio.data is a static offset
into the vCPU's run page, and I would expect far bigger explosions if the run
page is freed while the vCPU is still reachable.