public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Yonatan Maman <ymaman@nvidia.com>
Cc: nouveau@lists.freedesktop.org, Gal Shalom <GalShalom@nvidia.com>,
	kherbst@redhat.com, lyude@redhat.com, dakr@redhat.com,
	airlied@gmail.com, daniel@ffwll.ch,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] nouveau/dmem: Fix memory leak in `migrate_to_ram` upon copy error
Date: Mon, 7 Oct 2024 15:51:19 +0200	[thread overview]
Message-ID: <ZwPnV2OPJhOUcsU0@pollux> (raw)
In-Reply-To: <f9fa14c1-f487-4ad9-9bc9-7c1db6de1ae6@nvidia.com>

On Mon, Oct 07, 2024 at 03:28:22PM +0300, Yonatan Maman wrote:
> 
> 
> On 30/09/2024 14:20, Danilo Krummrich wrote:
> > External email: Use caution opening links or attachments
> > 
> > 
> > On Mon, Sep 23, 2024 at 01:54:58PM +0000, Yonatan Maman wrote:
> > > A copy push command might fail, causing `migrate_to_ram` to return a
> > > dirty HIGH_USER page to the user.
> > > 
> > > This exposes a security vulnerability in the nouveau driver. To prevent
> > > memory leaks in `migrate_to_ram` upon a copy error, allocate a zero
> > > page for the destination page.
> > 
> > So, you refer to the case where this function fails in nouveau_dmem_copy_one()?
> > 
> > If so, can you please explain why adding __GFP_ZERO to alloc_page_vma() helps
> > with that?
> > 
> 
> The nouveau_dmem_copy_one function ensures that the copy push command is
> sent to the device firmware but does not track whether it was executed
> successfully.
> 
> In the case of a copy error (e.g., firmware or hardware error), the command
> will be sent in the firmware channel, and nouveau_dmem_copy_one might
> succeed, as well as the migrate_to_ram function. Thus, a dirty page could be
> returned to the user.
> 
> It’s important to note that we attempted to use nouveau_fence_wait status to
> handle migration errors, but it does not catch all error types.
> 
> To avoid this vulnerability, we allocate a zero page. So that, in case of an
> error, a non-dirty (zero) page will be returned to the user.

I see, I got confused by calling this a 'memory leak'.

Please add this description in the commit message and avoid the term 'memory
leak' in this context.

> 
> > > 
> > > Signed-off-by: Yonatan Maman <Ymaman@Nvidia.com>
> > > Signed-off-by: Gal Shalom <GalShalom@Nvidia.com>
> > 
> > Since this is a bug, please also add a 'Fixes' tag, CC stable and add a
> > 'Co-developed-by' tag if appropriate.
> 
> sure, thanks, I will add, and push it as V2 patch-series.
> > 
> > > ---
> > >   drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > > index 6fb65b01d778..097bd3af0719 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > > @@ -193,7 +193,7 @@ static vm_fault_t nouveau_dmem_migrate_to_ram(struct vm_fault *vmf)
> > >        if (!spage || !(src & MIGRATE_PFN_MIGRATE))
> > >                goto done;
> > > 
> > > -     dpage = alloc_page_vma(GFP_HIGHUSER, vmf->vma, vmf->address);
> > > +     dpage = alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO, vmf->vma, vmf->address);
> > >        if (!dpage)
> > >                goto done;
> > > 
> > > --
> > > 2.34.1
> > > 
> 

  reply	other threads:[~2024-10-07 13:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240923135449.356244-1-Ymaman@Nvidia.com>
     [not found] ` <20240923135449.356244-3-Ymaman@Nvidia.com>
     [not found]   ` <ZvqJgMVBs2kAWguk@pollux>
2024-10-07 12:28     ` [PATCH 2/2] nouveau/dmem: Fix memory leak in `migrate_to_ram` upon copy error Yonatan Maman
2024-10-07 13:51       ` Danilo Krummrich [this message]
     [not found] ` <20240923135449.356244-2-Ymaman@Nvidia.com>
     [not found]   ` <ZvqHA76iSOYJexSh@pollux>
2024-10-07 12:35     ` [PATCH 1/2] nouveau/dmem: Fix privileged error in copy engine channel Yonatan Maman

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=ZwPnV2OPJhOUcsU0@pollux \
    --to=dakr@kernel.org \
    --cc=GalShalom@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=dakr@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kherbst@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ymaman@nvidia.com \
    /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