linux-kernel - Re: [PATCH] KVM: nVMX: WARN on any attempt to allocate shadow VMCS for vmcs02

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] [day] [month] [year] [list]

Date:   Wed, 26 Jan 2022 18:05:38 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: nVMX: WARN on any attempt to allocate shadow VMCS
 for vmcs02

On 1/26/22 17:22, Sean Christopherson wrote:
> I don't like preceeding, because that will likely lead to a crash and/or WARNs if
> KVM call the helper at the right time but with the wrong VMCS loaded, i.e. if
> vmcs01.shadow_vmcs is left NULL, as many paths assumes vmcs01 is allocated if they
> are reached with VMCS shadowing enabled.  At the very least, it will leak memory
> because vmcs02.shadow_vmcs is never freed.
> 
> Maybe this to try and clarify things?  Compile tested only...

Your patch is okay, just with an extra paragraph in the commit message:


The previous code WARNed but continued anyway with the allocation,
presumably in an attempt to avoid NULL pointer dereference.
However, alloc_vmcs (and hence alloc_shadow_vmcs) can fail, and
indeed the sole caller does:

         if (enable_shadow_vmcs && !alloc_shadow_vmcs(vcpu))
                 goto out_shadow_vmcs;

which makes it not a useful attempt.

Paolo