[PATCH RFC] KVM: x86/mmu: fix UAF in paging_update_accessed_dirty_bits

[PATCH RFC] KVM: x86/mmu: fix UAF in paging_update_accessed_dirty_bits

[Tadeusz Struk]

Syzbot reported an use-after-free bug in update_accessed_dirty_bits().
Fix this by checking if the memremap'ed pointer is still valid.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.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: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
Cc: <kvm@vger.kernel.org>
Cc: <stable@vger.kernel.org>
Fixes: bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs")
Link: https://syzkaller.appspot.com/bug?id=6cb6102a0a7b0c52060753dd62d070a1d1e71347
Reported-by: syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
---
 arch/x86/kvm/mmu/paging_tmpl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
index 708a5d297fe1..5cf4815d1c45 100644
--- a/arch/x86/kvm/mmu/paging_tmpl.h
+++ b/arch/x86/kvm/mmu/paging_tmpl.h
@@ -174,7 +174,7 @@ static int FNAME(cmpxchg_gpte)(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu,
 		pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
 		paddr = pfn << PAGE_SHIFT;
 		table = memremap(paddr, PAGE_SIZE, MEMREMAP_WB);
-		if (!table) {
+		if (!table || !access_ok(table, PAGE_SIZE)) {
 			mmap_read_unlock(current->mm);
 			return -EFAULT;
 		}
-- 
2.33.1

Re: [PATCH RFC] KVM: x86/mmu: fix UAF in paging_update_accessed_dirty_bits

[Sean Christopherson]

On Tue, Dec 14, 2021, Tadeusz Struk wrote:
> Syzbot reported an use-after-free bug in update_accessed_dirty_bits().
> Fix this by checking if the memremap'ed pointer is still valid.

...

> Fixes: bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs")
> Link: https://syzkaller.appspot.com/bug?id=6cb6102a0a7b0c52060753dd62d070a1d1e71347
> Reported-by: syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com
> Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
> ---
>  arch/x86/kvm/mmu/paging_tmpl.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
> index 708a5d297fe1..5cf4815d1c45 100644
> --- a/arch/x86/kvm/mmu/paging_tmpl.h
> +++ b/arch/x86/kvm/mmu/paging_tmpl.h
> @@ -174,7 +174,7 @@ static int FNAME(cmpxchg_gpte)(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu,
>  		pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;

Isn't this code flat out wrong?  vm_pgoff is usually the offset relative to the
file and has nothing to do with the pfn.  I see that remap_pfn_range_notrack()
stuffs "vma->vm_pgoff = pfn", but that's a weird quirk of that particular usage
of VM_PFNMAP that I'm guessing happened to align with the original usage of this
mess.  But unless there's magic I'm missing, vm_pgoff is not guaranteed to have
any relation to the pfn for any ol' VM_PFNMAP vma.

In other words, I suspect pfn and paddr are complete garbage, and adding the
access_ok() check masks that.

>  		paddr = pfn << PAGE_SHIFT;
>  		table = memremap(paddr, PAGE_SIZE, MEMREMAP_WB);
> -		if (!table) {
> +		if (!table || !access_ok(table, PAGE_SIZE)) {
>  			mmap_read_unlock(current->mm);
>  			return -EFAULT;
>  		}
> -- 
> 2.33.1
> 

Re: [PATCH RFC] KVM: x86/mmu: fix UAF in paging_update_accessed_dirty_bits

[Tadeusz Struk]

On 12/15/21 15:05, Sean Christopherson wrote:
>> @@ -174,7 +174,7 @@ static int FNAME(cmpxchg_gpte)(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu,
>>   		pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
> Isn't this code flat out wrong?  vm_pgoff is usually the offset relative to the
> file and has nothing to do with the pfn.  I see that remap_pfn_range_notrack()
> stuffs "vma->vm_pgoff = pfn", but that's a weird quirk of that particular usage
> of VM_PFNMAP that I'm guessing happened to align with the original usage of this
> mess.  But unless there's magic I'm missing, vm_pgoff is not guaranteed to have
> any relation to the pfn for any ol' VM_PFNMAP vma.
> 
> In other words, I suspect pfn and paddr are complete garbage, and adding the
> access_ok() check masks that.
> 

The answer to your question might be in the commit message of the original
commit that added this code:

bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs")

-- 
Thanks,
Tadeusz