All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Danilo Krummrich <dakr@redhat.com>
Cc: Takashi Iwai <tiwai@suse.de>,
	bskeggs@redhat.com, alex000young@gmail.com, security@kernel.org,
	kherbst@redhat.com, nouveau@lists.freedesktop.org,
	hackerzheng666@gmail.com, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, Zheng Wang <zyytlz.wz@163.com>
Subject: Re: [PATCH] drm/nouveau/mmu: fix Use after Free bug in nvkm_vmm_node_split
Date: Sat, 28 Jan 2023 09:13:51 +0100	[thread overview]
Message-ID: <87bkmjqdog.wl-tiwai@suse.de> (raw)
In-Reply-To: <63d485b2.170a0220.4af4c.d54f@mx.google.com>

On Sat, 28 Jan 2023 03:17:15 +0100,
Danilo Krummrich wrote:
> 
> On Fri, Jan 27, 2023 at 01:10:46PM +0100, Takashi Iwai wrote:
> > On Tue, 03 Jan 2023 15:07:55 +0100,
> > Takashi Iwai wrote:
> > > 
> > > On Fri, 30 Dec 2022 08:27:58 +0100,
> > > Zheng Wang wrote:
> > > > 
> > > > Here is a function call chain.
> > > > nvkm_vmm_pfn_map->nvkm_vmm_pfn_split_merge->nvkm_vmm_node_split
> > > > If nvkm_vma_tail return NULL in nvkm_vmm_node_split, it will
> > > > finally invoke nvkm_vmm_node_merge->nvkm_vmm_node_delete, which
> > > > will free the vma. However, nvkm_vmm_pfn_map didn't notice that.
> > > > It goes into next label and UAF happens.
> > > > 
> > > > Fix it by returning the return-value of nvkm_vmm_node_merge
> > > > instead of NULL.
> > > > 
> > > > Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
> > > 
> > > FWIW, CVE-2023-0030 has been assigned to this bug.
> > > It's a question whether it really deserves as a security issue, but a
> > > bug is a bug...
> > > 
> > > Ben, could you review this please?
> > 
> > A gentle ping as reminder.  The bug is still present.
> 
> This was also reported in [1]. I had a closer look and FWICT this code is fine
> and there isn't a bug.
> 
> Zheng Wang, the reporter of the BZ, also confirmed this to be a false positive
> from CodeQL.
> 
> Anyway, here's the explaination I also posted in the BZ:
> 
> "In nvkm_vmm_node_merge() nvkm_vmm_node_delete() is only called when prev is
> set. However, prev is NULL unless we enter the "if (vma->addr != addr)" path in
> nvkm_vmm_node_split(). In such a case the vma pointer, which is also passed to
> nvkm_vmm_node_merge(), is set to a freshly allocated struct nvkm_vma with
> nvkm_vma_tail() right before prev is set to the old vma pointer.
> 
> Hence, the only thing happening there when nvkm_vma_tail() fails in the
> "if (vma->size != size)" path is that either nvkm_vmm_node_merge() does nothing
> in case prev wasn't set or it merges and frees the new vma created in the
> "if (vma->addr != addr)" path. Or in other words the proper cleanup for the
> error condition is done.
> 
> I can't see any case where the original vma pointer given by nvkm_vmm_pfn_map()
> is actually freed."
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2157041

Thanks for the information!  Then we should try to dispute the CVE.
I'll ask our security team.


Takashi

> 
> - Danilo
> 
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > > 
> > > 
> > > thanks,
> > > 
> > > Takashi
> > > 
> > > > ---
> > > >  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > > index ae793f400ba1..84d6fc87b2e8 100644
> > > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > > @@ -937,8 +937,8 @@ nvkm_vmm_node_split(struct nvkm_vmm *vmm,
> > > >  	if (vma->size != size) {
> > > >  		struct nvkm_vma *tmp;
> > > >  		if (!(tmp = nvkm_vma_tail(vma, vma->size - size))) {
> > > > -			nvkm_vmm_node_merge(vmm, prev, vma, NULL, vma->size);
> > > > -			return NULL;
> > > > +			tmp = nvkm_vmm_node_merge(vmm, prev, vma, NULL, vma->size);
> > > > +			return tmp;
> > > >  		}
> > > >  		tmp->part = true;
> > > >  		nvkm_vmm_node_insert(vmm, tmp);
> > > > -- 
> > > > 2.25.1
> > > > 
> > 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Danilo Krummrich <dakr@redhat.com>
Cc: alex000young@gmail.com, security@kernel.org,
	Takashi Iwai <tiwai@suse.de>,
	nouveau@lists.freedesktop.org, hackerzheng666@gmail.com,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	bskeggs@redhat.com, Zheng Wang <zyytlz.wz@163.com>
Subject: Re: [Nouveau] [PATCH] drm/nouveau/mmu: fix Use after Free bug in nvkm_vmm_node_split
Date: Sat, 28 Jan 2023 09:13:51 +0100	[thread overview]
Message-ID: <87bkmjqdog.wl-tiwai@suse.de> (raw)
In-Reply-To: <63d485b2.170a0220.4af4c.d54f@mx.google.com>

On Sat, 28 Jan 2023 03:17:15 +0100,
Danilo Krummrich wrote:
> 
> On Fri, Jan 27, 2023 at 01:10:46PM +0100, Takashi Iwai wrote:
> > On Tue, 03 Jan 2023 15:07:55 +0100,
> > Takashi Iwai wrote:
> > > 
> > > On Fri, 30 Dec 2022 08:27:58 +0100,
> > > Zheng Wang wrote:
> > > > 
> > > > Here is a function call chain.
> > > > nvkm_vmm_pfn_map->nvkm_vmm_pfn_split_merge->nvkm_vmm_node_split
> > > > If nvkm_vma_tail return NULL in nvkm_vmm_node_split, it will
> > > > finally invoke nvkm_vmm_node_merge->nvkm_vmm_node_delete, which
> > > > will free the vma. However, nvkm_vmm_pfn_map didn't notice that.
> > > > It goes into next label and UAF happens.
> > > > 
> > > > Fix it by returning the return-value of nvkm_vmm_node_merge
> > > > instead of NULL.
> > > > 
> > > > Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
> > > 
> > > FWIW, CVE-2023-0030 has been assigned to this bug.
> > > It's a question whether it really deserves as a security issue, but a
> > > bug is a bug...
> > > 
> > > Ben, could you review this please?
> > 
> > A gentle ping as reminder.  The bug is still present.
> 
> This was also reported in [1]. I had a closer look and FWICT this code is fine
> and there isn't a bug.
> 
> Zheng Wang, the reporter of the BZ, also confirmed this to be a false positive
> from CodeQL.
> 
> Anyway, here's the explaination I also posted in the BZ:
> 
> "In nvkm_vmm_node_merge() nvkm_vmm_node_delete() is only called when prev is
> set. However, prev is NULL unless we enter the "if (vma->addr != addr)" path in
> nvkm_vmm_node_split(). In such a case the vma pointer, which is also passed to
> nvkm_vmm_node_merge(), is set to a freshly allocated struct nvkm_vma with
> nvkm_vma_tail() right before prev is set to the old vma pointer.
> 
> Hence, the only thing happening there when nvkm_vma_tail() fails in the
> "if (vma->size != size)" path is that either nvkm_vmm_node_merge() does nothing
> in case prev wasn't set or it merges and frees the new vma created in the
> "if (vma->addr != addr)" path. Or in other words the proper cleanup for the
> error condition is done.
> 
> I can't see any case where the original vma pointer given by nvkm_vmm_pfn_map()
> is actually freed."
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2157041

Thanks for the information!  Then we should try to dispute the CVE.
I'll ask our security team.


Takashi

> 
> - Danilo
> 
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > > 
> > > 
> > > thanks,
> > > 
> > > Takashi
> > > 
> > > > ---
> > > >  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > > index ae793f400ba1..84d6fc87b2e8 100644
> > > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > > @@ -937,8 +937,8 @@ nvkm_vmm_node_split(struct nvkm_vmm *vmm,
> > > >  	if (vma->size != size) {
> > > >  		struct nvkm_vma *tmp;
> > > >  		if (!(tmp = nvkm_vma_tail(vma, vma->size - size))) {
> > > > -			nvkm_vmm_node_merge(vmm, prev, vma, NULL, vma->size);
> > > > -			return NULL;
> > > > +			tmp = nvkm_vmm_node_merge(vmm, prev, vma, NULL, vma->size);
> > > > +			return tmp;
> > > >  		}
> > > >  		tmp->part = true;
> > > >  		nvkm_vmm_node_insert(vmm, tmp);
> > > > -- 
> > > > 2.25.1
> > > > 
> > 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Danilo Krummrich <dakr@redhat.com>
Cc: alex000young@gmail.com, security@kernel.org, kherbst@redhat.com,
	nouveau@lists.freedesktop.org, hackerzheng666@gmail.com,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	bskeggs@redhat.com, Zheng Wang <zyytlz.wz@163.com>
Subject: Re: [PATCH] drm/nouveau/mmu: fix Use after Free bug in nvkm_vmm_node_split
Date: Sat, 28 Jan 2023 09:13:51 +0100	[thread overview]
Message-ID: <87bkmjqdog.wl-tiwai@suse.de> (raw)
In-Reply-To: <63d485b2.170a0220.4af4c.d54f@mx.google.com>

On Sat, 28 Jan 2023 03:17:15 +0100,
Danilo Krummrich wrote:
> 
> On Fri, Jan 27, 2023 at 01:10:46PM +0100, Takashi Iwai wrote:
> > On Tue, 03 Jan 2023 15:07:55 +0100,
> > Takashi Iwai wrote:
> > > 
> > > On Fri, 30 Dec 2022 08:27:58 +0100,
> > > Zheng Wang wrote:
> > > > 
> > > > Here is a function call chain.
> > > > nvkm_vmm_pfn_map->nvkm_vmm_pfn_split_merge->nvkm_vmm_node_split
> > > > If nvkm_vma_tail return NULL in nvkm_vmm_node_split, it will
> > > > finally invoke nvkm_vmm_node_merge->nvkm_vmm_node_delete, which
> > > > will free the vma. However, nvkm_vmm_pfn_map didn't notice that.
> > > > It goes into next label and UAF happens.
> > > > 
> > > > Fix it by returning the return-value of nvkm_vmm_node_merge
> > > > instead of NULL.
> > > > 
> > > > Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
> > > 
> > > FWIW, CVE-2023-0030 has been assigned to this bug.
> > > It's a question whether it really deserves as a security issue, but a
> > > bug is a bug...
> > > 
> > > Ben, could you review this please?
> > 
> > A gentle ping as reminder.  The bug is still present.
> 
> This was also reported in [1]. I had a closer look and FWICT this code is fine
> and there isn't a bug.
> 
> Zheng Wang, the reporter of the BZ, also confirmed this to be a false positive
> from CodeQL.
> 
> Anyway, here's the explaination I also posted in the BZ:
> 
> "In nvkm_vmm_node_merge() nvkm_vmm_node_delete() is only called when prev is
> set. However, prev is NULL unless we enter the "if (vma->addr != addr)" path in
> nvkm_vmm_node_split(). In such a case the vma pointer, which is also passed to
> nvkm_vmm_node_merge(), is set to a freshly allocated struct nvkm_vma with
> nvkm_vma_tail() right before prev is set to the old vma pointer.
> 
> Hence, the only thing happening there when nvkm_vma_tail() fails in the
> "if (vma->size != size)" path is that either nvkm_vmm_node_merge() does nothing
> in case prev wasn't set or it merges and frees the new vma created in the
> "if (vma->addr != addr)" path. Or in other words the proper cleanup for the
> error condition is done.
> 
> I can't see any case where the original vma pointer given by nvkm_vmm_pfn_map()
> is actually freed."
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2157041

Thanks for the information!  Then we should try to dispute the CVE.
I'll ask our security team.


Takashi

> 
> - Danilo
> 
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > > 
> > > 
> > > thanks,
> > > 
> > > Takashi
> > > 
> > > > ---
> > > >  drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > > index ae793f400ba1..84d6fc87b2e8 100644
> > > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> > > > @@ -937,8 +937,8 @@ nvkm_vmm_node_split(struct nvkm_vmm *vmm,
> > > >  	if (vma->size != size) {
> > > >  		struct nvkm_vma *tmp;
> > > >  		if (!(tmp = nvkm_vma_tail(vma, vma->size - size))) {
> > > > -			nvkm_vmm_node_merge(vmm, prev, vma, NULL, vma->size);
> > > > -			return NULL;
> > > > +			tmp = nvkm_vmm_node_merge(vmm, prev, vma, NULL, vma->size);
> > > > +			return tmp;
> > > >  		}
> > > >  		tmp->part = true;
> > > >  		nvkm_vmm_node_insert(vmm, tmp);
> > > > -- 
> > > > 2.25.1
> > > > 
> > 
> 

  reply	other threads:[~2023-01-28  8:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30  7:27 [PATCH] drm/nouveau/mmu: fix Use after Free bug in nvkm_vmm_node_split Zheng Wang
2022-12-30  7:27 ` [Nouveau] " Zheng Wang
2022-12-30  7:27 ` Zheng Wang
2023-01-03 14:07 ` Takashi Iwai
2023-01-03 14:07   ` Takashi Iwai
2023-01-03 14:07   ` [Nouveau] " Takashi Iwai
2023-01-27 12:10   ` Takashi Iwai
2023-01-27 12:10     ` Takashi Iwai
2023-01-27 12:10     ` Takashi Iwai
2023-01-28  2:17     ` [Nouveau] " Danilo Krummrich
2023-01-28  2:17       ` Danilo Krummrich
2023-01-28  2:17       ` Danilo Krummrich
2023-01-28  8:13       ` Takashi Iwai [this message]
2023-01-28  8:13         ` Takashi Iwai
2023-01-28  8:13         ` [Nouveau] " Takashi Iwai

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=87bkmjqdog.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alex000young@gmail.com \
    --cc=bskeggs@redhat.com \
    --cc=dakr@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hackerzheng666@gmail.com \
    --cc=kherbst@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=security@kernel.org \
    --cc=zyytlz.wz@163.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 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.