linux-kernel - Re: [PATCH V2] KVM: sev: Fix potential overflow send|recieve_update

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: <Y+LeAfc61yrYerhk@google.com>
Date:   Tue, 7 Feb 2023 23:25:53 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Peter Gonda <pgonda@...gle.com>
Cc:     kvm@...r.kernel.org, Andy Nguyen <theflow@...gle.com>,
        Thomas Lendacky <thomas.lendacky@....com>,
        David Rientjes <rientjes@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] KVM: sev: Fix potential overflow
 send|recieve_update_data

For now at least, I want to keep with "KVM: SVM:" instead of using "KVM: SEV:".
Many commits that touch SEV aren't strictly isolated to SEV, which means the "SEV"
tag is unreliable.  There's also the question of taggin SEV vs. SEV-ES vs. SEV-SNP.
It's usually easy enough to squeeze SEV (or SEV-ES or SNP) into the shortlog, e.g.

  KVM: SVM: Fix potential overflow in SEV's send|receive_update_data()

On Tue, Feb 07, 2023, Peter Gonda wrote:
> KVM_SEV_SEND_UPDATE_DATA and KVM_SEV_RECEIVE_UPDATE_DATA have an integer
> overflow issue. Params.guest_len and offset are both 32bite wide, with a

"32 bits"

> large params.guest_len the check to confirm a page boundary is not
> crossed can falsely pass:
> 
>     /* Check if we are crossing the page boundary *
>     offset = params.guest_uaddr & (PAGE_SIZE - 1);
>     if ((params.guest_len + offset > PAGE_SIZE))
> 
> Add an additional check to this conditional to confirm that

Eh, "to this conditional" is unnecessarily precise.

> params.guest_len itself is not greater than PAGE_SIZE.
> 
> The current code is can only overflow with a params.guest_len of greater

"is can", though I vote to omit the "current code" part entirely, it should be
obvious that this is talking about the pre-patched code.

> than 0xfffff000. And the FW spec says these commands fail with lengths
> greater than 16KB. So this issue should not be a security concern

Slightly reworded, how about this for the "not a security concern" disclaimer?

  Note, this isn't a security concern as overflow can happen if and only if
  params.guest_len is greater than 0xfffff000, and the FW spec says these
  commands fail with lengths greater than 16KB, i.e. the PSP will detect
  KVM's goof.

No need to send a v3, I'll fix up the changelog when applying.  Holler if you
disagree with anything though.

Thanks!