[tl;dr: there could be a /dev/usb bug only affecting KASAN
configurations, jump to the end to skip the analysis and get to the bug
details]
On 12/09/19 15:54, Vitaly Kuznetsov wrote:
> Hm, the bisection seems bogus but the stack points us to the following
> piece of code:
>
> 4776) if (kvm_vcpu_map(vcpu, gpa_to_gfn(vmptr), &map)) {
> <skip>
> 4783) return nested_vmx_failValid(vcpu,
> 4784) VMXERR_VMPTRLD_INCORRECT_VMCS_REVISION_ID);
> 4785) }
> 4786)
> 4787) new_vmcs12 = map.hva;
> 4788)
> *4789) if (new_vmcs12->hdr.revision_id != VMCS12_REVISION ||
> 4790) (new_vmcs12->hdr.shadow_vmcs &&
> 4791) !nested_cpu_has_vmx_shadow_vmcs(vcpu))) {
>
> the reported problem seems to be on VMCS12 region access but it's part
> of guest memory and we successfuly managed to map it. We're definitely
> within 1-page range. Maybe KASAN is just wrong here?
Here is the relevant part of the syzkaller repro:
syz_kvm_setup_cpu$x86(r1, 0xffffffffffffffff,
&(0x7f0000000000/0x18000)=nil, 0x0, 0x133, 0x0, 0x0, 0xff7d)
r3 = syz_open_dev$usb(&(0x7f0000000080)='/dev/bus/usb/00#/00#\x00',
0x40000fffffd, 0x200800000000042)
mmap$IORING_OFF_SQES(&(0x7f0000007000/0x2000)=nil, 0x2000, 0x4, 0x13,
r3, 0x10000000)
syz_kvm_setup_cpu$x86(0xffffffffffffffff, r2,
&(0x7f0000000000/0x18000)=nil, 0x0, 0xfefd, 0x40, 0x0, 0xfffffffffffffdd4)
ioctl$KVM_RUN(r2, 0xae80, 0x0)
The mmap$IORING_OFF_SQES is just a normal mmap from a device, which
replaces the previous mapping for guest memory and in particular
0x7f0000007000 which is the VMCS (from the C reproducer: "#define
ADDR_VAR_VMCS 0x7000").
The previous mapping is freed with do_munmap and then repopulated in
usbdev_mmap with remap_pfn_range. In KVM this means that kvm_vcpu_map
goes through hva_to_pfn_remapped, which correctly calls get_page via
kvm_get_pfn. (Note that although drivers/usb/core/devio.c's usbdev_mmap
sets VM_IO *after* calling remap_pfn_range, remap_pfn_range itself
helpfully sets it before calling remap_p4d_range. And anyway KVM is
looking at vma->vm_flags under mmap_sem, which is held during mmap).
So, KVM should be doing the right thing. Now, the error is:
> Read of size 4 at addr ffff888091e10000 by task syz-executor758/10006
> The buggy address belongs to the object at ffff888091e109c0
> The buggy address is located 2496 bytes to the left of
> 8192-byte region [ffff888091e109c0, ffff888091e129c0)
And given the use of remap_pfn_range in devusb_mmap, the simplest
explanation could be that USB expects kmalloc-8k to return 8k-aligned
values, but this is not true anymore with KASAN. CCing Dmitry, Greg and
linux-usb.
Paolo
