linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>, linux-kernel@vger.kernel.org
Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH RFC 6/9] s390/pci_mmio: fully validate the VMA before calling follow_pte()
Date: Fri, 10 Sep 2021 14:48:49 +0200	[thread overview]
Message-ID: <dc672aa05a596a79c97339c14c09cc22559ffd10.camel@linux.ibm.com> (raw)
In-Reply-To: <d9ec2387-2645-796e-af47-26f22516f7fa@redhat.com>

On Fri, 2021-09-10 at 11:23 +0200, David Hildenbrand wrote:
> On 10.09.21 10:22, Niklas Schnelle wrote:
> > On Thu, 2021-09-09 at 16:59 +0200, David Hildenbrand wrote:
> > > We should not walk/touch page tables outside of VMA boundaries when
> > > holding only the mmap sem in read mode. Evil user space can modify the
> > > VMA layout just before this function runs and e.g., trigger races with
> > > page table removal code since commit dd2283f2605e ("mm: mmap: zap pages
> > > with read mmap_sem in munmap").
> > > 
> > > find_vma() does not check if the address is >= the VMA start address;
> > > use vma_lookup() instead.
> > > 
> > > Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
> > > Signed-off-by: David Hildenbrand <david@redhat.com>
> > > ---
> > >   arch/s390/pci/pci_mmio.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
> > > index ae683aa623ac..c5b35ea129cf 100644
> > > --- a/arch/s390/pci/pci_mmio.c
> > > +++ b/arch/s390/pci/pci_mmio.c
> > > @@ -159,7 +159,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
> > >   
> > >   	mmap_read_lock(current->mm);
> > >   	ret = -EINVAL;
> > > -	vma = find_vma(current->mm, mmio_addr);
> > > +	vma = vma_lookup(current->mm, mmio_addr);
> > >   	if (!vma)
> > >   		goto out_unlock_mmap;
> > >   	if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
> > > @@ -298,7 +298,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long, mmio_addr,
> > >   
> > >   	mmap_read_lock(current->mm);
> > >   	ret = -EINVAL;
> > > -	vma = find_vma(current->mm, mmio_addr);
> > > +	vma = vma_lookup(current->mm, mmio_addr);
> > >   	if (!vma)
> > >   		goto out_unlock_mmap;
> > >   	if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
> > 
> > Oh wow great find thanks! If I may say so these are not great function
> > names. Looking at the code vma_lookup() is inded find_vma() plus the
> > check that the looked up address is indeed inside the vma.
> > 
> 
> IIRC, vma_lookup() was introduced fairly recently. Before that, this 
> additional check was open coded (and still are in some instances). It's 
> confusing, I agree.
> 
> > I think this is pretty independent of the rest of the patches, so do
> > you want me to apply this patch independently or do you want to wait
> > for the others?
> 
> Sure, please go ahead and apply independently. It'd be great if you 
> could give it a quick sanity test, although I don't expect surprises -- 
> unfortunately, the environment I have easily at hand is not very well 
> suited (#cpu, #mem, #disk ...) for anything that exceeds basic compile 
> tests (and even cross-compiling is significantly faster ...).

Yes and even if you had more hardware this code path is only hit by
very specialized workloads doing MMIO access of PCI devices from
userspace. I did test with such a workload (ib_send_bw test utility)
and all looks good.

Applied and will be sent out by Heiko or Vasily as part of the s390
tree.


> 
> > In any case:
> > 
> > Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
> > 
> 
> Thanks!
> 


  reply	other threads:[~2021-09-10 12:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 14:59 [PATCH RFC 0/9] s390: fixes, cleanups and optimizations for page table walkers David Hildenbrand
2021-09-09 14:59 ` [PATCH RFC 1/9] s390/gmap: validate VMA in __gmap_zap() David Hildenbrand
2021-09-09 14:59 ` [PATCH RFC 2/9] s390/gmap: don't unconditionally call pte_unmap_unlock() " David Hildenbrand
2021-09-09 14:59 ` [PATCH RFC 3/9] s390/mm: validate VMA in PGSTE manipulation functions David Hildenbrand
2021-09-09 14:59 ` [PATCH RFC 4/9] s390/mm: fix VMA and page table handling code in storage key handling functions David Hildenbrand
2021-09-09 14:59 ` [PATCH RFC 5/9] s390/uv: fully validate the VMA before calling follow_page() David Hildenbrand
2021-09-10 14:14   ` Liam Howlett
2021-09-09 14:59 ` [PATCH RFC 6/9] s390/pci_mmio: fully validate the VMA before calling follow_pte() David Hildenbrand
2021-09-10  8:22   ` Niklas Schnelle
2021-09-10  9:23     ` David Hildenbrand
2021-09-10 12:48       ` Niklas Schnelle [this message]
2021-09-10 14:12       ` Liam Howlett
2021-09-10 14:31         ` Niklas Schnelle
2021-09-10 14:52           ` Liam Howlett
2021-09-09 14:59 ` [PATCH RFC 7/9] s390/mm: no need for pte_alloc_map_lock() if we know the pmd is present David Hildenbrand
2021-09-09 14:59 ` [PATCH RFC 8/9] s390/mm: optimize set_guest_storage_key() David Hildenbrand
2021-09-09 14:59 ` [PATCH RFC 9/9] s390/mm: optimize reset_guest_reference_bit() David Hildenbrand

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=dc672aa05a596a79c97339c14c09cc22559ffd10.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.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;
as well as URLs for NNTP newsgroup(s).