| Message ID | 20210208201940.1258328-1-seanjc@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: Use kvm_pfn_t for local PFN variable in hva_to_pfn_remapped() | expand |
On 08/02/21 21:19, Sean Christopherson wrote: > Use kvm_pfn_t, a.k.a. u64, for the local 'pfn' variable when retrieving > a so called "remapped" hva/pfn pair. In theory, the hva could resolve to > a pfn in high memory on a 32-bit kernel. > > This bug was inadvertantly exposed by commit bd2fae8da794 ("KVM: do not > assume PTE is writable after follow_pfn"), which added an error PFN value > to the mix, causing gcc to comlain about overflowing the unsigned long. > > arch/x86/kvm/../../../virt/kvm/kvm_main.c: In function ‘hva_to_pfn_remapped’: > include/linux/kvm_host.h:89:30: error: conversion from ‘long long unsigned int’ > to ‘long unsigned int’ changes value from > ‘9218868437227405314’ to ‘2’ [-Werror=overflow] > 89 | #define KVM_PFN_ERR_RO_FAULT (KVM_PFN_ERR_MASK + 2) > | ^ > virt/kvm/kvm_main.c:1935:9: note: in expansion of macro ‘KVM_PFN_ERR_RO_FAULT’ > > Cc: stable@vger.kernel.org > Fixes: add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up") > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > > I don't actually know that it's possible for a remapped pfn to be a 64-bit > value on a stock kernel. But, backporting a one-liner is far easier and > safer than trying to audit all possible flows. :-) > > virt/kvm/kvm_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index ee4ac2618ec5..001b9de4e727 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -1906,7 +1906,7 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, > bool write_fault, bool *writable, > kvm_pfn_t *p_pfn) > { > - unsigned long pfn; > + kvm_pfn_t pfn; > pte_t *ptep; > spinlock_t *ptl; > int r; > Queued, thanks. Paolo
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index ee4ac2618ec5..001b9de4e727 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1906,7 +1906,7 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, bool write_fault, bool *writable, kvm_pfn_t *p_pfn) { - unsigned long pfn; + kvm_pfn_t pfn; pte_t *ptep; spinlock_t *ptl; int r;
Use kvm_pfn_t, a.k.a. u64, for the local 'pfn' variable when retrieving a so called "remapped" hva/pfn pair. In theory, the hva could resolve to a pfn in high memory on a 32-bit kernel. This bug was inadvertantly exposed by commit bd2fae8da794 ("KVM: do not assume PTE is writable after follow_pfn"), which added an error PFN value to the mix, causing gcc to comlain about overflowing the unsigned long. arch/x86/kvm/../../../virt/kvm/kvm_main.c: In function ‘hva_to_pfn_remapped’: include/linux/kvm_host.h:89:30: error: conversion from ‘long long unsigned int’ to ‘long unsigned int’ changes value from ‘9218868437227405314’ to ‘2’ [-Werror=overflow] 89 | #define KVM_PFN_ERR_RO_FAULT (KVM_PFN_ERR_MASK + 2) | ^ virt/kvm/kvm_main.c:1935:9: note: in expansion of macro ‘KVM_PFN_ERR_RO_FAULT’ Cc: stable@vger.kernel.org Fixes: add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up") Signed-off-by: Sean Christopherson <seanjc@google.com> --- I don't actually know that it's possible for a remapped pfn to be a 64-bit value on a stock kernel. But, backporting a one-liner is far easier and safer than trying to audit all possible flows. :-) virt/kvm/kvm_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)