linux-kernel - Re: KVM: Warn if mark_page_dirty() is called without an active vCPU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bfc53985a178f43a3a21796f33449570cf9e4649.camel@infradead.org>
Date:   Thu, 13 Jan 2022 13:22:20 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     butterflyhuangxx@...il.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, seanjc@...gle.com,
        Cornelia Huck <cohuck@...hat.com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        David Hildenbrand <david@...hat.com>,
        linux-s390 <linux-s390@...r.kernel.org>,
        Thomas Huth <thuth@...hat.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>
Subject: Re: KVM: Warn if mark_page_dirty() is called without an active vCPU

On Thu, 2022-01-13 at 13:51 +0100, Christian Borntraeger wrote:
> > Btw, that get_map_page() in arch/s390/kvm/interrupt.c looks like it has
> > the same use-after-free problem that kvm_map_gfn() used to have. It
> > probably wants converting to the new gfn_to_pfn_cache.
> > 
> > Take a look at how I resolve the same issue for delivering Xen event
> > channel interrupts.
> 
> Do you have a commit ID for your Xen event channel fix?

14243b387137 ("KVM: x86/xen: Add KVM_IRQ_ROUTING_XEN_EVTCHN and event
channel delivery") and the commits reworking the gfn_to_pfn_cache which
lead up to it.

Questions: In your kvm_set_routing_entry() where it calls
gmap_translate() to turn the summary_addr and ind_addr from guest
addresses to userspace virtual addresses, what protects those
translations? If the gmap changes before kvm_set_routing_entry() even
returns, what ensures that the IRQ gets retranslated?

And later in adapter_indicators_set() where you take that userspace
virtual address and pass it to your get_map_page() function, the same
question: what if userspace does a concurrent mmap() and changes the
physical page that the userspace address points to? 

In the latter case, at least it does look like you don't support
external memory accessed only by a PFN without having a corresponding
struct page. So at least you don't end up accessing a page that can now
belong to *another* guest, because the original underlying page is
locked. You're probably OK in that case, so it's just the gmap changing
that we need to focus on?

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)