All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Jan Kara <jack@suse.cz>,
	andrew Morton <akpm@linux-foundation.org>,
	Linux MM <linux-mm@kvack.org>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	Mel Gorman <mgorman@suse.de>, stable <stable@vger.kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	John Hubbard <jhubbard@nvidia.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK" 
	<linux-media@vger.kernel.org>
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
Date: Mon, 5 Oct 2020 20:16:12 +0200	[thread overview]
Message-ID: <CAKMK7uHom6FGgsarnYRaW25Ta4cfrap+GMKgz27Y7bRYFUnmUw@mail.gmail.com> (raw)
In-Reply-To: <20201005175746.GA4734@nvidia.com>

On Mon, Oct 5, 2020 at 7:58 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Mon, Oct 05, 2020 at 07:53:08PM +0200, Jan Kara wrote:
> > On Mon 05-10-20 14:38:54, Jason Gunthorpe wrote:
> > > When get_vaddr_frames() does its hacky follow_pfn() loop it should never
> > > be allowed to extract a struct page from a normal VMA. This could allow a
> > > serious use-after-free problem on any kernel memory.
> > >
> > > Restrict this to only work on VMA's with one of VM_IO | VM_PFNMAP
> > > set. This limits the use-after-free problem to only IO memory, which while
> > > still serious, is an improvement.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: 8025e5ddf9c1 ("[media] mm: Provide new get_vaddr_frames() helper")
> > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > >  mm/frame_vector.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> > > index 10f82d5643b6de..26cb20544b6c37 100644
> > > +++ b/mm/frame_vector.c
> > > @@ -99,6 +99,10 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
> > >             if (ret >= nr_frames || start < vma->vm_end)
> > >                     break;
> > >             vma = find_vma_intersection(mm, start, start + 1);
> > > +           if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
> > > +                   ret = -EINVAL;
> > > +                   goto out;
> > > +           }
> > >     } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
> >
> > Hum, I fail to see how this helps. If vma has no VM_IO or VM_PFNMAP flag,
> > we'd exit the loop (to out: label) anyway due to the loop termination
> > condition and why not return the frames we already have? Furthermore
> > find_vma_intersection() can return NULL which would oops in your check
> > then. What am I missing?
>
> Oh, nothing, you are right. It just didn't read naturally because
> hitting the wrong kind of VMA should be an error condition :\

Afaik these mmio maps should all be VM_DONTEXPAND (or at least the
ones in drivers/gpu are all), so not sure why we need the loop here.
But maybe there's some drivers that don't set that, or have other
funny things going on with userspace piecing the mmap together, and
I'm not going to audit them all :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	Jan Kara <jack@suse.cz>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	John Hubbard <jhubbard@nvidia.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>, Linux MM <linux-mm@kvack.org>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Mel Gorman <mgorman@suse.de>,
	andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
Date: Mon, 5 Oct 2020 20:16:12 +0200	[thread overview]
Message-ID: <CAKMK7uHom6FGgsarnYRaW25Ta4cfrap+GMKgz27Y7bRYFUnmUw@mail.gmail.com> (raw)
In-Reply-To: <20201005175746.GA4734@nvidia.com>

On Mon, Oct 5, 2020 at 7:58 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Mon, Oct 05, 2020 at 07:53:08PM +0200, Jan Kara wrote:
> > On Mon 05-10-20 14:38:54, Jason Gunthorpe wrote:
> > > When get_vaddr_frames() does its hacky follow_pfn() loop it should never
> > > be allowed to extract a struct page from a normal VMA. This could allow a
> > > serious use-after-free problem on any kernel memory.
> > >
> > > Restrict this to only work on VMA's with one of VM_IO | VM_PFNMAP
> > > set. This limits the use-after-free problem to only IO memory, which while
> > > still serious, is an improvement.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: 8025e5ddf9c1 ("[media] mm: Provide new get_vaddr_frames() helper")
> > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > >  mm/frame_vector.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> > > index 10f82d5643b6de..26cb20544b6c37 100644
> > > +++ b/mm/frame_vector.c
> > > @@ -99,6 +99,10 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
> > >             if (ret >= nr_frames || start < vma->vm_end)
> > >                     break;
> > >             vma = find_vma_intersection(mm, start, start + 1);
> > > +           if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
> > > +                   ret = -EINVAL;
> > > +                   goto out;
> > > +           }
> > >     } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
> >
> > Hum, I fail to see how this helps. If vma has no VM_IO or VM_PFNMAP flag,
> > we'd exit the loop (to out: label) anyway due to the loop termination
> > condition and why not return the frames we already have? Furthermore
> > find_vma_intersection() can return NULL which would oops in your check
> > then. What am I missing?
>
> Oh, nothing, you are right. It just didn't read naturally because
> hitting the wrong kind of VMA should be an error condition :\

Afaik these mmio maps should all be VM_DONTEXPAND (or at least the
ones in drivers/gpu are all), so not sure why we need the loop here.
But maybe there's some drivers that don't set that, or have other
funny things going on with userspace piecing the mmap together, and
I'm not going to audit them all :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	Jan Kara <jack@suse.cz>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	John Hubbard <jhubbard@nvidia.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>, Linux MM <linux-mm@kvack.org>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Mel Gorman <mgorman@suse.de>,
	andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>
Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
Date: Mon, 5 Oct 2020 20:16:12 +0200	[thread overview]
Message-ID: <CAKMK7uHom6FGgsarnYRaW25Ta4cfrap+GMKgz27Y7bRYFUnmUw@mail.gmail.com> (raw)
In-Reply-To: <20201005175746.GA4734@nvidia.com>

On Mon, Oct 5, 2020 at 7:58 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Mon, Oct 05, 2020 at 07:53:08PM +0200, Jan Kara wrote:
> > On Mon 05-10-20 14:38:54, Jason Gunthorpe wrote:
> > > When get_vaddr_frames() does its hacky follow_pfn() loop it should never
> > > be allowed to extract a struct page from a normal VMA. This could allow a
> > > serious use-after-free problem on any kernel memory.
> > >
> > > Restrict this to only work on VMA's with one of VM_IO | VM_PFNMAP
> > > set. This limits the use-after-free problem to only IO memory, which while
> > > still serious, is an improvement.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: 8025e5ddf9c1 ("[media] mm: Provide new get_vaddr_frames() helper")
> > > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > >  mm/frame_vector.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> > > index 10f82d5643b6de..26cb20544b6c37 100644
> > > +++ b/mm/frame_vector.c
> > > @@ -99,6 +99,10 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
> > >             if (ret >= nr_frames || start < vma->vm_end)
> > >                     break;
> > >             vma = find_vma_intersection(mm, start, start + 1);
> > > +           if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
> > > +                   ret = -EINVAL;
> > > +                   goto out;
> > > +           }
> > >     } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
> >
> > Hum, I fail to see how this helps. If vma has no VM_IO or VM_PFNMAP flag,
> > we'd exit the loop (to out: label) anyway due to the loop termination
> > condition and why not return the frames we already have? Furthermore
> > find_vma_intersection() can return NULL which would oops in your check
> > then. What am I missing?
>
> Oh, nothing, you are right. It just didn't read naturally because
> hitting the wrong kind of VMA should be an error condition :\

Afaik these mmio maps should all be VM_DONTEXPAND (or at least the
ones in drivers/gpu are all), so not sure why we need the loop here.
But maybe there's some drivers that don't set that, or have other
funny things going on with userspace piecing the mmap together, and
I'm not going to audit them all :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-10-05 18:16 UTC|newest]

Thread overview: 145+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 17:38 [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Jason Gunthorpe
2020-10-05 17:38 ` Jason Gunthorpe
2020-10-05 17:47 ` Jason Gunthorpe
2020-10-05 17:47   ` Jason Gunthorpe
2020-10-05 17:47   ` Jason Gunthorpe
2020-10-06  3:36   ` Andrew Morton
2020-10-06  3:36     ` Andrew Morton
2020-10-06  3:36     ` Andrew Morton
2020-10-06 11:57     ` Jason Gunthorpe
2020-10-06 11:57       ` Jason Gunthorpe
2020-10-06 11:57       ` Jason Gunthorpe
2020-10-05 17:53 ` Jan Kara
2020-10-05 17:53   ` Jan Kara
2020-10-05 17:53   ` Jan Kara
2020-10-05 17:57   ` Jason Gunthorpe
2020-10-05 17:57     ` Jason Gunthorpe
2020-10-05 17:57     ` Jason Gunthorpe
2020-10-05 18:16     ` Daniel Vetter [this message]
2020-10-05 18:16       ` Daniel Vetter
2020-10-05 18:16       ` Daniel Vetter
2020-10-05 18:16       ` Daniel Vetter
2020-10-06 11:56     ` Daniel Vetter
2020-10-06 11:56       ` Daniel Vetter
2020-10-06 11:56       ` Daniel Vetter
2020-10-06 11:56       ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2020-10-02 17:53 [PATCH 1/2] mm/frame-vec: Drop gup_flags from get_vaddr_frames() Daniel Vetter
2020-10-02 17:53 ` [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Daniel Vetter
2020-10-02 17:53   ` Daniel Vetter
2020-10-02 17:53   ` Daniel Vetter
2020-10-02 18:06   ` Jason Gunthorpe
2020-10-02 18:06     ` Jason Gunthorpe
2020-10-02 18:06     ` Jason Gunthorpe
2020-10-02 18:16     ` Daniel Vetter
2020-10-02 18:16       ` Daniel Vetter
2020-10-02 18:16       ` Daniel Vetter
2020-10-02 23:31       ` Jason Gunthorpe
2020-10-02 23:31         ` Jason Gunthorpe
2020-10-02 23:31         ` Jason Gunthorpe
2020-10-03  8:34         ` Oded Gabbay
2020-10-03  8:34           ` Oded Gabbay
2020-10-03  8:34           ` Oded Gabbay
2020-10-03  9:40         ` Daniel Vetter
2020-10-03  9:40           ` Daniel Vetter
2020-10-03  9:40           ` Daniel Vetter
2020-10-04 12:50           ` Jason Gunthorpe
2020-10-04 12:50             ` Jason Gunthorpe
2020-10-04 12:50             ` Jason Gunthorpe
2020-10-04 16:09             ` Daniel Vetter
2020-10-04 16:09               ` Daniel Vetter
2020-10-04 16:09               ` Daniel Vetter
2020-10-05 17:28               ` Jason Gunthorpe
2020-10-05 17:28                 ` Jason Gunthorpe
2020-10-05 17:28                 ` Jason Gunthorpe
2020-10-05 18:16                 ` Daniel Vetter
2020-10-05 18:16                   ` Daniel Vetter
2020-10-05 18:16                   ` Daniel Vetter
2020-10-05 18:37                   ` Jason Gunthorpe
2020-10-05 18:37                     ` Jason Gunthorpe
2020-10-05 18:37                     ` Jason Gunthorpe
2020-10-05 18:54                     ` Daniel Vetter
2020-10-05 18:54                       ` Daniel Vetter
2020-10-05 18:54                       ` Daniel Vetter
2020-10-05 22:43                       ` Daniel Vetter
2020-10-05 22:43                         ` Daniel Vetter
2020-10-05 22:43                         ` Daniel Vetter
2020-10-05 23:41                         ` Jason Gunthorpe
2020-10-05 23:41                           ` Jason Gunthorpe
2020-10-05 23:41                           ` Jason Gunthorpe
2020-10-06  6:23                           ` Daniel Vetter
2020-10-06  6:23                             ` Daniel Vetter
2020-10-06  6:23                             ` Daniel Vetter
2020-10-06 12:26                             ` Jason Gunthorpe
2020-10-06 12:26                               ` Jason Gunthorpe
2020-10-06 12:26                               ` Jason Gunthorpe
2020-10-06 13:08                               ` Daniel Vetter
2020-10-06 13:08                                 ` Daniel Vetter
2020-10-06 13:08                                 ` Daniel Vetter
2020-10-07 10:47           ` Marek Szyprowski
2020-10-07 10:47             ` Marek Szyprowski
2020-10-07 10:47             ` Marek Szyprowski
2020-10-07 12:01             ` Daniel Vetter
2020-10-07 12:01               ` Daniel Vetter
2020-10-07 12:01               ` Daniel Vetter
2020-10-07 12:33               ` Marek Szyprowski
2020-10-07 12:33                 ` Marek Szyprowski
2020-10-07 12:33                 ` Marek Szyprowski
2020-10-07 12:44                 ` Jason Gunthorpe
2020-10-07 12:44                   ` Jason Gunthorpe
2020-10-07 12:44                   ` Jason Gunthorpe
2020-10-07 12:47                   ` Tomasz Figa
2020-10-07 12:47                     ` Tomasz Figa
2020-10-07 12:47                     ` Tomasz Figa
2020-10-07 12:58                     ` Daniel Vetter
2020-10-07 12:58                       ` Daniel Vetter
2020-10-07 12:58                       ` Daniel Vetter
2020-10-07 13:06                       ` Jason Gunthorpe
2020-10-07 13:06                         ` Jason Gunthorpe
2020-10-07 13:06                         ` Jason Gunthorpe
2020-10-07 13:34                         ` Tomasz Figa
2020-10-07 13:34                           ` Tomasz Figa
2020-10-07 13:34                           ` Tomasz Figa
2020-10-07 13:42                           ` Jason Gunthorpe
2020-10-07 13:42                             ` Jason Gunthorpe
2020-10-07 13:42                             ` Jason Gunthorpe
2020-10-07 14:08                           ` Daniel Vetter
2020-10-07 14:08                             ` Daniel Vetter
2020-10-07 14:08                             ` Daniel Vetter
2020-10-07 14:11                             ` Tomasz Figa
2020-10-07 14:11                               ` Tomasz Figa
2020-10-07 14:11                               ` Tomasz Figa
2020-10-07 14:22                               ` Daniel Vetter
2020-10-07 14:22                                 ` Daniel Vetter
2020-10-07 14:22                                 ` Daniel Vetter
2020-10-07 15:05                                 ` Tomasz Figa
2020-10-07 15:05                                   ` Tomasz Figa
2020-10-07 15:05                                   ` Tomasz Figa
2020-10-07 14:58                               ` Jason Gunthorpe
2020-10-07 14:58                                 ` Jason Gunthorpe
2020-10-07 14:58                                 ` Jason Gunthorpe
2020-10-07 13:06         ` Tomasz Figa
2020-10-07 13:06           ` Tomasz Figa
2020-10-07 13:06           ` Tomasz Figa
2020-10-07 13:14           ` Jason Gunthorpe
2020-10-07 13:14             ` Jason Gunthorpe
2020-10-07 13:14             ` Jason Gunthorpe
2020-10-05 15:03     ` Jan Kara
2020-10-05 15:03       ` Jan Kara
2020-10-05 15:03       ` Jan Kara
2020-10-02 22:39   ` John Hubbard
2020-10-02 22:39     ` John Hubbard
2020-10-02 22:39     ` John Hubbard
2020-10-03  9:45     ` Daniel Vetter
2020-10-03  9:45       ` Daniel Vetter
2020-10-03  9:45       ` Daniel Vetter
2020-10-03 22:52       ` John Hubbard
2020-10-03 22:52         ` John Hubbard
2020-10-03 22:52         ` John Hubbard
2020-10-03 23:24         ` Jason Gunthorpe
2020-10-03 23:24           ` Jason Gunthorpe
2020-10-03 23:24           ` Jason Gunthorpe
2020-10-04 11:20           ` Daniel Vetter
2020-10-04 11:20             ` Daniel Vetter
2020-10-04 11:20             ` Daniel Vetter
2020-10-05 17:35             ` Jason Gunthorpe
2020-10-05 17:35               ` Jason Gunthorpe
2020-10-05 17:35               ` Jason Gunthorpe

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=CAKMK7uHom6FGgsarnYRaW25Ta4cfrap+GMKgz27Y7bRYFUnmUw@mail.gmail.com \
    --to=daniel.vetter@ffwll.ch \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hans.verkuil@cisco.com \
    --cc=jack@suse.cz \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    --cc=mgorman@suse.de \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /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.