All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: John Hubbard <jhubbard@nvidia.com>, LKML <linux-kernel@vger.kernel.org>
Cc: Souptick Joarder <jrdr.linux@gmail.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] KVM: SVM: fix svn_pin_memory()'s use of get_user_pages_fast()
Date: Tue, 26 May 2020 09:33:27 +0200	[thread overview]
Message-ID: <87imgj6th4.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20200526062207.1360225-2-jhubbard@nvidia.com>

John Hubbard <jhubbard@nvidia.com> writes:

> There are two problems in svn_pin_memory():
>
> 1) The return value of get_user_pages_fast() is stored in an
> unsigned long, although the declared return value is of type int.
> This will not cause any symptoms, but it is misleading.
> Fix this by changing the type of npinned to "int".
>
> 2) The number of pages passed into get_user_pages_fast() is stored
> in an unsigned long, even though get_user_pages_fast() accepts an
> int. This means that it is possible to silently overflow the number
> of pages.
>
> Fix this by adding a WARN_ON_ONCE() and an early error return. The
> npages variable is left as an unsigned long for convenience in
> checking for overflow.
>
> Fixes: 89c505809052 ("KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA command")
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Sean Christopherson <sean.j.christopherson@intel.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> Cc: Wanpeng Li <wanpengli@tencent.com>
> Cc: Jim Mattson <jmattson@google.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: kvm@vger.kernel.org
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
>  arch/x86/kvm/svm/sev.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 89f7f3aebd31..9693db1af57c 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -313,7 +313,8 @@ static struct page **sev_pin_memory(struct kvm *kvm, unsigned long uaddr,
>  				    int write)
>  {
>  	struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
> -	unsigned long npages, npinned, size;
> +	unsigned long npages, size;
> +	int npinned;
>  	unsigned long locked, lock_limit;
>  	struct page **pages;
>  	unsigned long first, last;
> @@ -333,6 +334,9 @@ static struct page **sev_pin_memory(struct kvm *kvm, unsigned long uaddr,
>  		return NULL;
>  	}
>  
> +	if (WARN_ON_ONCE(npages > INT_MAX))
> +		return NULL;
> +

I bit unrelated to this patch, but callers of sev_pin_memory() treat
NULL differently:

sev_launch_secret()/svm_register_enc_region() return -ENOMEM
sev_dbg_crypt() returns -EFAULT

Should we switch to ERR_PTR() to preserve the error?

>  	/* Avoid using vmalloc for smaller buffers. */
>  	size = npages * sizeof(struct page *);
>  	if (size > PAGE_SIZE)

Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>

-- 
Vitaly


  reply	other threads:[~2020-05-26  7:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26  6:22 [PATCH 0/2] KVM: SVM: convert get_user_pages() --> pin_user_pages(), bug fixes John Hubbard
2020-05-26  6:22 ` [PATCH 1/2] KVM: SVM: fix svn_pin_memory()'s use of get_user_pages_fast() John Hubbard
2020-05-26  7:33   ` Vitaly Kuznetsov [this message]
2020-06-30  3:10     ` John Hubbard
2020-05-26  6:22 ` [PATCH 2/2] KVM: SVM: convert get_user_pages() --> pin_user_pages() John Hubbard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87imgj6th4.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jhubbard@nvidia.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=jrdr.linux@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.