From: Sean Christopherson <seanjc@google.com>
To: Tadeusz Struk <tadeusz.struk@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, kvm@vger.kernel.org, stable@vger.kernel.org,
syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com
Subject: Re: [PATCH RFC] KVM: x86/mmu: fix UAF in paging_update_accessed_dirty_bits
Date: Wed, 15 Dec 2021 23:05:01 +0000 [thread overview]
Message-ID: <Ybp0naX/ZTG9FNEa@google.com> (raw)
In-Reply-To: <20211214232039.851405-1-tadeusz.struk@linaro.org>
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
>
next prev parent reply other threads:[~2021-12-15 23:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-14 23:20 [PATCH RFC] KVM: x86/mmu: fix UAF in paging_update_accessed_dirty_bits Tadeusz Struk
2021-12-15 23:05 ` Sean Christopherson [this message]
2021-12-16 0:18 ` Tadeusz Struk
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=Ybp0naX/ZTG9FNEa@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
--cc=syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com \
--cc=tadeusz.struk@linaro.org \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox