linux-kernel - Re: [PATCH 02/16] KVM: x86: clamp host mapping level to max_level in kvm_mmu_max_mapping

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:   Fri, 13 Aug 2021 16:28:40 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        isaku.yamahata@...el.com, David Matlack <dmatlack@...gle.com>,
        peterx@...hat.com
Subject: Re: [PATCH 02/16] KVM: x86: clamp host mapping level to max_level in
 kvm_mmu_max_mapping_level

On Sat, Aug 07, 2021, Paolo Bonzini wrote:
> This patch started as a way to make kvm_mmu_hugepage_adjust a bit simpler,
> in preparation for switching it to struct kvm_page_fault, but it does
> fix a microscopic bug in zapping collapsible PTEs.

I think this also fixes a bug where userspace backs guest memory with a 1gb hugepage
but only assigns a subset of the page to the guest.  1gb pages would be disallowed
by the memslot, but not 2mb.  kvm_mmu_max_mapping_level() would fall through to the
host_pfn_mapping_level() logic, see the 1gb huge, and map the whole thing into the
guest.  I can't imagine any userspace would actually do something like that, but the
failure mode is serious enough that it warrants a Fixes: + Cc: stable@.