linux-kernel - Re: There is a null-ptr-deref bug in kvm_dirty_ring_get in virt/kvm/dirty

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 17 Nov 2021 17:49:14 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     "Woodhouse, David" <dwmw@...zon.co.uk>,
        "butterflyhuangxx@...il.com" <butterflyhuangxx@...il.com>
Cc:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: There is a null-ptr-deref bug in kvm_dirty_ring_get in
 virt/kvm/dirty_ring.c

On 11/17/21 10:46, Woodhouse, David wrote:
>> The remaining
>> option would be just "do not mark the page as dirty if the ring buffer
>> is active".  This is feasible because userspace itself has passed the
>> shared info gfn; but again, it's ugly...
> I think I am coming to quite like that 'remaining option' as long as we
> rephrase it as follows:
> 
>   KVM does not mark the shared_info page as dirty, and userspace is
>   expected to*assume*  that it is dirty at all times. It's used for
>   delivering event channel interrupts and the overhead of marking it
>   dirty each time is just pointless.

For the case of dirty-bitmap, one solution could be to only set a bool 
and actually mark the page dirty lazily, at the time of 
KVM_GET_DIRTY_LOG.  For dirty-ring, I agree that it's easiest if 
userspace just "knows" the page is dirty.

Paolo