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: <X/yT8H883tUkQV2M@google.com>
Date:   Mon, 11 Jan 2021 10:07:44 -0800
From:   Sean Christopherson <seanjc@...gle.com>
To:     Tom Lendacky <thomas.lendacky@....com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        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, Borislav Petkov <bp@...e.de>,
        Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH 01/13] KVM: SVM: Free sev_asid_bitmap during init if SEV
 setup fails

On Mon, Jan 11, 2021, Tom Lendacky wrote:
> On 1/8/21 6:47 PM, Sean Christopherson wrote:
> > Free sev_asid_bitmap if the reclaim bitmap allocation fails, othwerise
> > it will be leaked as sev_hardware_teardown() frees the bitmaps if and
> > only if SEV is fully enabled (which obviously isn't the case if SEV
> > setup fails).
> 
> The svm_sev_enabled() function is only based on CONFIG_KVM_AMD_SEV and
> max_sev_asid. So sev_hardware_teardown() should still free everything if it
> was allocated since we never change max_sev_asid, no?

Aha!  You're correct.  This is needed once svm_sev_enabled() is gone, but is not
an actual bug in upstream.

I created the commit before the long New Years weekend, but stupidly didn't
write a changelog.  I then forgot that my series effectively introduce the bug
and incorrectly moved this patch to the front and treated it as an upstream bug
fix when retroactively writing the changelog.

Thanks!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ