Re: [syzbot] [kvm?] WARNING in __kvm_gpc_refresh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18/03/2024 21:25, David Woodhouse wrote:
On Mon, 2024-03-18 at 09:25 -0700, syzbot wrote:
Hello,

syzbot found the following issue on:

HEAD commit:    277100b3d5fe Merge tag 'block-6.9-20240315' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17c96aa5180000
kernel config:  https://syzkaller.appspot.com/x/.config?x=1c6662240382da2
dashboard link: https://syzkaller.appspot.com/bug?extid=106a4f72b0474e1d1b33
compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14358231180000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=110ed231180000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-277100b3.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6872e049b27c/vmlinux-277100b3.xz
kernel image: https://storage.googleapis.com/syzbot-assets/68ec7230df0f/bzImage-277100b3.xz

static int __kvm_gpc_refresh(struct gfn_to_pfn_cache *gpc, gpa_t gpa, unsigned long uhva,
                              unsigned long len)
{
         unsigned long page_offset;
         bool unmap_old = false;
         unsigned long old_uhva;
         kvm_pfn_t old_pfn;
         bool hva_change = false;
         void *old_khva;
         int ret;

         /* Either gpa or uhva must be valid, but not both */
         if (WARN_ON_ONCE(kvm_is_error_gpa(gpa) == kvm_is_error_hva(uhva)))
                 return -EINVAL;

Hm, that comment doesn't match the code. It says "not both", but the
code also catches the "neither" case. I think the gpa is in %rbx and
uhva is in %r12, so this is indeed the 'neither' case.

Is it expected that we can end up with a cache marked active, but with
the address not valid? Maybe through a race condition with deactive? or
more likely than that?

Paul, we should probably add ourselves to MAINTAINERS for pfncache.c


Sorry, missed this. Yes, given the changes we've made, we ought to step up.

  Paul





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux