All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] gpu: ttm: fix GPF in ttm_bo_release
@ 2021-07-07 18:51 ` Pavel Skripkin
  0 siblings, 0 replies; 14+ messages in thread
From: Pavel Skripkin @ 2021-07-07 18:51 UTC (permalink / raw)
  To: christian.koenig, ray.huang, airlied
  Cc: dri-devel, linux-kernel, Pavel Skripkin

My local syzbot instance hit GPF in ttm_bo_release().
Unfortunately, syzbot didn't produce a reproducer for this, but I
found out possible scenario:

drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
				     (bo embedded in this object)
  ttm_bo_init()
    ttm_bo_init_reserved()
      ttm_resource_alloc()
        man->func->alloc()       <-- allocation failure
      ttm_bo_put()
	ttm_bo_release()
	  ttm_mem_io_free()      <-- bo->resource == NULL passed
				     as second argument
	     *GPF*

So, I've added check in ttm_bo_release() to avoid passing
NULL as second argument to ttm_mem_io_free().

Fail log:

KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66
Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f
RSP: 0018:ffffc900141df968 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90010da0000
RDX: 0000000000000004 RSI: ffffffff84513ea3 RDI: ffff888041fbc010
RBP: ffff888041fbc010 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000020 R14: ffff88806b258800 R15: ffff88806b258a38
FS:  00007fa6e9845640(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fad61265e18 CR3: 000000005ad79000 CR4: 0000000000350ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422
 kref_put include/linux/kref.h:65 [inline]
 ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline]
 ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050
 ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074
 drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228

Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
---
 drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1b950b45cf4b..15eb97459eab 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -419,7 +419,8 @@ static void ttm_bo_release(struct kref *kref)
 			bo->bdev->funcs->release_notify(bo);
 
 		drm_vma_offset_remove(bdev->vma_manager, &bo->base.vma_node);
-		ttm_mem_io_free(bdev, bo->resource);
+		if (bo->resource)
+			ttm_mem_io_free(bdev, bo->resource);
 	}
 
 	if (!dma_resv_test_signaled(bo->base.resv, true) ||
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* [PATCH] gpu: ttm: fix GPF in ttm_bo_release
@ 2021-07-07 18:51 ` Pavel Skripkin
  0 siblings, 0 replies; 14+ messages in thread
From: Pavel Skripkin @ 2021-07-07 18:51 UTC (permalink / raw)
  To: christian.koenig, ray.huang, airlied
  Cc: Pavel Skripkin, linux-kernel, dri-devel

My local syzbot instance hit GPF in ttm_bo_release().
Unfortunately, syzbot didn't produce a reproducer for this, but I
found out possible scenario:

drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
				     (bo embedded in this object)
  ttm_bo_init()
    ttm_bo_init_reserved()
      ttm_resource_alloc()
        man->func->alloc()       <-- allocation failure
      ttm_bo_put()
	ttm_bo_release()
	  ttm_mem_io_free()      <-- bo->resource == NULL passed
				     as second argument
	     *GPF*

So, I've added check in ttm_bo_release() to avoid passing
NULL as second argument to ttm_mem_io_free().

Fail log:

KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66
Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f
RSP: 0018:ffffc900141df968 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90010da0000
RDX: 0000000000000004 RSI: ffffffff84513ea3 RDI: ffff888041fbc010
RBP: ffff888041fbc010 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000020 R14: ffff88806b258800 R15: ffff88806b258a38
FS:  00007fa6e9845640(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fad61265e18 CR3: 000000005ad79000 CR4: 0000000000350ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422
 kref_put include/linux/kref.h:65 [inline]
 ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline]
 ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050
 ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074
 drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228

Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
---
 drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1b950b45cf4b..15eb97459eab 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -419,7 +419,8 @@ static void ttm_bo_release(struct kref *kref)
 			bo->bdev->funcs->release_notify(bo);
 
 		drm_vma_offset_remove(bdev->vma_manager, &bo->base.vma_node);
-		ttm_mem_io_free(bdev, bo->resource);
+		if (bo->resource)
+			ttm_mem_io_free(bdev, bo->resource);
 	}
 
 	if (!dma_resv_test_signaled(bo->base.resv, true) ||
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release
  2021-07-07 18:51 ` Pavel Skripkin
@ 2021-07-08  6:49   ` Christian König
  -1 siblings, 0 replies; 14+ messages in thread
From: Christian König @ 2021-07-08  6:49 UTC (permalink / raw)
  To: Pavel Skripkin, ray.huang, airlied; +Cc: dri-devel, linux-kernel

Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
> My local syzbot instance hit GPF in ttm_bo_release().
> Unfortunately, syzbot didn't produce a reproducer for this, but I
> found out possible scenario:
>
> drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
> 				     (bo embedded in this object)
>    ttm_bo_init()
>      ttm_bo_init_reserved()
>        ttm_resource_alloc()
>          man->func->alloc()       <-- allocation failure
>        ttm_bo_put()
> 	ttm_bo_release()
> 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
> 				     as second argument
> 	     *GPF*
>
> So, I've added check in ttm_bo_release() to avoid passing
> NULL as second argument to ttm_mem_io_free().

There is another ocassion of this a bit down before we call 
ttm_bo_move_to_lru_tail() apart from that good catch.

But I'm wondering if we should make the functions NULL save instead of 
the external check.

Thanks,
Christian.

>
> Fail log:
>
> KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
> CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
> RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66
> Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f
> RSP: 0018:ffffc900141df968 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90010da0000
> RDX: 0000000000000004 RSI: ffffffff84513ea3 RDI: ffff888041fbc010
> RBP: ffff888041fbc010 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
> R13: 0000000000000020 R14: ffff88806b258800 R15: ffff88806b258a38
> FS:  00007fa6e9845640(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fad61265e18 CR3: 000000005ad79000 CR4: 0000000000350ee0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422
>   kref_put include/linux/kref.h:65 [inline]
>   ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline]
>   ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050
>   ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074
>   drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228
>
> Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 1b950b45cf4b..15eb97459eab 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -419,7 +419,8 @@ static void ttm_bo_release(struct kref *kref)
>   			bo->bdev->funcs->release_notify(bo);
>   
>   		drm_vma_offset_remove(bdev->vma_manager, &bo->base.vma_node);
> -		ttm_mem_io_free(bdev, bo->resource);
> +		if (bo->resource)
> +			ttm_mem_io_free(bdev, bo->resource);
>   	}
>   
>   	if (!dma_resv_test_signaled(bo->base.resv, true) ||


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release
@ 2021-07-08  6:49   ` Christian König
  0 siblings, 0 replies; 14+ messages in thread
From: Christian König @ 2021-07-08  6:49 UTC (permalink / raw)
  To: Pavel Skripkin, ray.huang, airlied; +Cc: linux-kernel, dri-devel

Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
> My local syzbot instance hit GPF in ttm_bo_release().
> Unfortunately, syzbot didn't produce a reproducer for this, but I
> found out possible scenario:
>
> drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
> 				     (bo embedded in this object)
>    ttm_bo_init()
>      ttm_bo_init_reserved()
>        ttm_resource_alloc()
>          man->func->alloc()       <-- allocation failure
>        ttm_bo_put()
> 	ttm_bo_release()
> 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
> 				     as second argument
> 	     *GPF*
>
> So, I've added check in ttm_bo_release() to avoid passing
> NULL as second argument to ttm_mem_io_free().

There is another ocassion of this a bit down before we call 
ttm_bo_move_to_lru_tail() apart from that good catch.

But I'm wondering if we should make the functions NULL save instead of 
the external check.

Thanks,
Christian.

>
> Fail log:
>
> KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
> CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
> RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66
> Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f
> RSP: 0018:ffffc900141df968 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90010da0000
> RDX: 0000000000000004 RSI: ffffffff84513ea3 RDI: ffff888041fbc010
> RBP: ffff888041fbc010 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
> R13: 0000000000000020 R14: ffff88806b258800 R15: ffff88806b258a38
> FS:  00007fa6e9845640(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fad61265e18 CR3: 000000005ad79000 CR4: 0000000000350ee0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422
>   kref_put include/linux/kref.h:65 [inline]
>   ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline]
>   ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050
>   ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074
>   drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228
>
> Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 1b950b45cf4b..15eb97459eab 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -419,7 +419,8 @@ static void ttm_bo_release(struct kref *kref)
>   			bo->bdev->funcs->release_notify(bo);
>   
>   		drm_vma_offset_remove(bdev->vma_manager, &bo->base.vma_node);
> -		ttm_mem_io_free(bdev, bo->resource);
> +		if (bo->resource)
> +			ttm_mem_io_free(bdev, bo->resource);
>   	}
>   
>   	if (!dma_resv_test_signaled(bo->base.resv, true) ||


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release
       [not found]   ` <20210708113701.4cea7989@gmail.com>
@ 2021-07-08 10:09       ` Pavel Skripkin
  0 siblings, 0 replies; 14+ messages in thread
From: Pavel Skripkin @ 2021-07-08 10:09 UTC (permalink / raw)
  To: Christian König, ray.huang, airlied; +Cc: dri-devel, linux-kernel

On Thu, 8 Jul 2021 11:37:01 +0300
Pavel Skripkin <paskripkin@gmail.com> wrote:

> On Thu, 8 Jul 2021 08:49:48 +0200
> Christian König <christian.koenig@amd.com> wrote:
> 
> > Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
> > > My local syzbot instance hit GPF in ttm_bo_release().
> > > Unfortunately, syzbot didn't produce a reproducer for this, but I
> > > found out possible scenario:
> > >
> > > drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
> > > 				     (bo embedded in this object)
> > >    ttm_bo_init()
> > >      ttm_bo_init_reserved()
> > >        ttm_resource_alloc()
> > >          man->func->alloc()       <-- allocation failure
> > >        ttm_bo_put()
> > > 	ttm_bo_release()
> > > 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
> > > 				     as second argument
> > > 	     *GPF*
> > >
> > > So, I've added check in ttm_bo_release() to avoid passing
> > > NULL as second argument to ttm_mem_io_free().
> 
> Hi, Christian!
> 
> Thank you for quick feedback :)
> 
> > 
> > There is another ocassion of this a bit down before we call 
> > ttm_bo_move_to_lru_tail() apart from that good catch.
> > 
> 
> Did you mean, that ttm_bo_move_to_lru_tail() should have NULL check
> too? I checked it's realization, and, I think, NULL check is necessary
> there, since mem pointer is dereferenced w/o any checking
> 
> > But I'm wondering if we should make the functions NULL save instead
> > of the external check.
> > 
> 
> I tried to find more possible scenarios of GPF in ttm_bo_release(),
> but I didn't find one. But, yes, moving NULL check inside
> ttm_mem_io_free() is more general approach and it will defend this
> function from GPFs in the future.
> 
> 
> 
> With regards,
> Pavel Skripkin
> 

I misclicked and sent this email to Christian privately :(

Added all thread participants back, sorry.



With regards,
Pavel Skripkin

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release
@ 2021-07-08 10:09       ` Pavel Skripkin
  0 siblings, 0 replies; 14+ messages in thread
From: Pavel Skripkin @ 2021-07-08 10:09 UTC (permalink / raw)
  To: Christian König, ray.huang, airlied; +Cc: linux-kernel, dri-devel

On Thu, 8 Jul 2021 11:37:01 +0300
Pavel Skripkin <paskripkin@gmail.com> wrote:

> On Thu, 8 Jul 2021 08:49:48 +0200
> Christian König <christian.koenig@amd.com> wrote:
> 
> > Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
> > > My local syzbot instance hit GPF in ttm_bo_release().
> > > Unfortunately, syzbot didn't produce a reproducer for this, but I
> > > found out possible scenario:
> > >
> > > drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
> > > 				     (bo embedded in this object)
> > >    ttm_bo_init()
> > >      ttm_bo_init_reserved()
> > >        ttm_resource_alloc()
> > >          man->func->alloc()       <-- allocation failure
> > >        ttm_bo_put()
> > > 	ttm_bo_release()
> > > 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
> > > 				     as second argument
> > > 	     *GPF*
> > >
> > > So, I've added check in ttm_bo_release() to avoid passing
> > > NULL as second argument to ttm_mem_io_free().
> 
> Hi, Christian!
> 
> Thank you for quick feedback :)
> 
> > 
> > There is another ocassion of this a bit down before we call 
> > ttm_bo_move_to_lru_tail() apart from that good catch.
> > 
> 
> Did you mean, that ttm_bo_move_to_lru_tail() should have NULL check
> too? I checked it's realization, and, I think, NULL check is necessary
> there, since mem pointer is dereferenced w/o any checking
> 
> > But I'm wondering if we should make the functions NULL save instead
> > of the external check.
> > 
> 
> I tried to find more possible scenarios of GPF in ttm_bo_release(),
> but I didn't find one. But, yes, moving NULL check inside
> ttm_mem_io_free() is more general approach and it will defend this
> function from GPFs in the future.
> 
> 
> 
> With regards,
> Pavel Skripkin
> 

I misclicked and sent this email to Christian privately :(

Added all thread participants back, sorry.



With regards,
Pavel Skripkin

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release
  2021-07-08 10:09       ` Pavel Skripkin
@ 2021-07-08 10:56         ` Christian König
  -1 siblings, 0 replies; 14+ messages in thread
From: Christian König @ 2021-07-08 10:56 UTC (permalink / raw)
  To: Pavel Skripkin, ray.huang, airlied; +Cc: dri-devel, linux-kernel

Am 08.07.21 um 12:09 schrieb Pavel Skripkin:
> On Thu, 8 Jul 2021 11:37:01 +0300
> Pavel Skripkin <paskripkin@gmail.com> wrote:
>
>> On Thu, 8 Jul 2021 08:49:48 +0200
>> Christian König <christian.koenig@amd.com> wrote:
>>
>>> Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
>>>> My local syzbot instance hit GPF in ttm_bo_release().
>>>> Unfortunately, syzbot didn't produce a reproducer for this, but I
>>>> found out possible scenario:
>>>>
>>>> drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
>>>> 				     (bo embedded in this object)
>>>>     ttm_bo_init()
>>>>       ttm_bo_init_reserved()
>>>>         ttm_resource_alloc()
>>>>           man->func->alloc()       <-- allocation failure
>>>>         ttm_bo_put()
>>>> 	ttm_bo_release()
>>>> 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
>>>> 				     as second argument
>>>> 	     *GPF*
>>>>
>>>> So, I've added check in ttm_bo_release() to avoid passing
>>>> NULL as second argument to ttm_mem_io_free().
>> Hi, Christian!
>>
>> Thank you for quick feedback :)
>>
>>> There is another ocassion of this a bit down before we call
>>> ttm_bo_move_to_lru_tail() apart from that good catch.
>>>
>> Did you mean, that ttm_bo_move_to_lru_tail() should have NULL check
>> too?

Yes, exactly that.

>>   I checked it's realization, and, I think, NULL check is necessary
>> there, since mem pointer is dereferenced w/o any checking
>>
>>> But I'm wondering if we should make the functions NULL save instead
>>> of the external check.
>>>
>> I tried to find more possible scenarios of GPF in ttm_bo_release(),
>> but I didn't find one. But, yes, moving NULL check inside
>> ttm_mem_io_free() is more general approach and it will defend this
>> function from GPFs in the future.
>>
>>
>>
>> With regards,
>> Pavel Skripkin
>>
> I misclicked and sent this email to Christian privately :(
>
> Added all thread participants back, sorry.

No problem.

Do you want to update your patch or should I take care of this?

Thanks,
Christian.

>
>
>
> With regards,
> Pavel Skripkin


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release
@ 2021-07-08 10:56         ` Christian König
  0 siblings, 0 replies; 14+ messages in thread
From: Christian König @ 2021-07-08 10:56 UTC (permalink / raw)
  To: Pavel Skripkin, ray.huang, airlied; +Cc: linux-kernel, dri-devel

Am 08.07.21 um 12:09 schrieb Pavel Skripkin:
> On Thu, 8 Jul 2021 11:37:01 +0300
> Pavel Skripkin <paskripkin@gmail.com> wrote:
>
>> On Thu, 8 Jul 2021 08:49:48 +0200
>> Christian König <christian.koenig@amd.com> wrote:
>>
>>> Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
>>>> My local syzbot instance hit GPF in ttm_bo_release().
>>>> Unfortunately, syzbot didn't produce a reproducer for this, but I
>>>> found out possible scenario:
>>>>
>>>> drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
>>>> 				     (bo embedded in this object)
>>>>     ttm_bo_init()
>>>>       ttm_bo_init_reserved()
>>>>         ttm_resource_alloc()
>>>>           man->func->alloc()       <-- allocation failure
>>>>         ttm_bo_put()
>>>> 	ttm_bo_release()
>>>> 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
>>>> 				     as second argument
>>>> 	     *GPF*
>>>>
>>>> So, I've added check in ttm_bo_release() to avoid passing
>>>> NULL as second argument to ttm_mem_io_free().
>> Hi, Christian!
>>
>> Thank you for quick feedback :)
>>
>>> There is another ocassion of this a bit down before we call
>>> ttm_bo_move_to_lru_tail() apart from that good catch.
>>>
>> Did you mean, that ttm_bo_move_to_lru_tail() should have NULL check
>> too?

Yes, exactly that.

>>   I checked it's realization, and, I think, NULL check is necessary
>> there, since mem pointer is dereferenced w/o any checking
>>
>>> But I'm wondering if we should make the functions NULL save instead
>>> of the external check.
>>>
>> I tried to find more possible scenarios of GPF in ttm_bo_release(),
>> but I didn't find one. But, yes, moving NULL check inside
>> ttm_mem_io_free() is more general approach and it will defend this
>> function from GPFs in the future.
>>
>>
>>
>> With regards,
>> Pavel Skripkin
>>
> I misclicked and sent this email to Christian privately :(
>
> Added all thread participants back, sorry.

No problem.

Do you want to update your patch or should I take care of this?

Thanks,
Christian.

>
>
>
> With regards,
> Pavel Skripkin


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release
  2021-07-08 10:56         ` Christian König
@ 2021-07-08 11:04           ` Pavel Skripkin
  -1 siblings, 0 replies; 14+ messages in thread
From: Pavel Skripkin @ 2021-07-08 11:04 UTC (permalink / raw)
  To: Christian König; +Cc: ray.huang, airlied, dri-devel, linux-kernel

On Thu, 8 Jul 2021 12:56:19 +0200
Christian König <christian.koenig@amd.com> wrote:

> Am 08.07.21 um 12:09 schrieb Pavel Skripkin:
> > On Thu, 8 Jul 2021 11:37:01 +0300
> > Pavel Skripkin <paskripkin@gmail.com> wrote:
> >
> >> On Thu, 8 Jul 2021 08:49:48 +0200
> >> Christian König <christian.koenig@amd.com> wrote:
> >>
> >>> Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
> >>>> My local syzbot instance hit GPF in ttm_bo_release().
> >>>> Unfortunately, syzbot didn't produce a reproducer for this, but I
> >>>> found out possible scenario:
> >>>>
> >>>> drm_gem_vram_create()            <-- drm_gem_vram_object
> >>>> kzalloced (bo embedded in this object)
> >>>>     ttm_bo_init()
> >>>>       ttm_bo_init_reserved()
> >>>>         ttm_resource_alloc()
> >>>>           man->func->alloc()       <-- allocation failure
> >>>>         ttm_bo_put()
> >>>> 	ttm_bo_release()
> >>>> 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
> >>>> 				     as second argument
> >>>> 	     *GPF*
> >>>>
> >>>> So, I've added check in ttm_bo_release() to avoid passing
> >>>> NULL as second argument to ttm_mem_io_free().
> >> Hi, Christian!
> >>
> >> Thank you for quick feedback :)
> >>
> >>> There is another ocassion of this a bit down before we call
> >>> ttm_bo_move_to_lru_tail() apart from that good catch.
> >>>
> >> Did you mean, that ttm_bo_move_to_lru_tail() should have NULL check
> >> too?
> 
> Yes, exactly that.
> 
> >>   I checked it's realization, and, I think, NULL check is necessary
> >> there, since mem pointer is dereferenced w/o any checking
> >>
> >>> But I'm wondering if we should make the functions NULL save
> >>> instead of the external check.
> >>>
> >> I tried to find more possible scenarios of GPF in ttm_bo_release(),
> >> but I didn't find one. But, yes, moving NULL check inside
> >> ttm_mem_io_free() is more general approach and it will defend this
> >> function from GPFs in the future.
> >>
> >>
> >>
> >> With regards,
> >> Pavel Skripkin
> >>
> > I misclicked and sent this email to Christian privately :(
> >
> > Added all thread participants back, sorry.
> 
> No problem.
> 
> Do you want to update your patch or should I take care of this?
> 

Yes, I will send v2 soon. Thank you!




With regards,
Pavel Skripkin

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH] gpu: ttm: fix GPF in ttm_bo_release
@ 2021-07-08 11:04           ` Pavel Skripkin
  0 siblings, 0 replies; 14+ messages in thread
From: Pavel Skripkin @ 2021-07-08 11:04 UTC (permalink / raw)
  To: Christian König; +Cc: airlied, ray.huang, linux-kernel, dri-devel

On Thu, 8 Jul 2021 12:56:19 +0200
Christian König <christian.koenig@amd.com> wrote:

> Am 08.07.21 um 12:09 schrieb Pavel Skripkin:
> > On Thu, 8 Jul 2021 11:37:01 +0300
> > Pavel Skripkin <paskripkin@gmail.com> wrote:
> >
> >> On Thu, 8 Jul 2021 08:49:48 +0200
> >> Christian König <christian.koenig@amd.com> wrote:
> >>
> >>> Am 07.07.21 um 20:51 schrieb Pavel Skripkin:
> >>>> My local syzbot instance hit GPF in ttm_bo_release().
> >>>> Unfortunately, syzbot didn't produce a reproducer for this, but I
> >>>> found out possible scenario:
> >>>>
> >>>> drm_gem_vram_create()            <-- drm_gem_vram_object
> >>>> kzalloced (bo embedded in this object)
> >>>>     ttm_bo_init()
> >>>>       ttm_bo_init_reserved()
> >>>>         ttm_resource_alloc()
> >>>>           man->func->alloc()       <-- allocation failure
> >>>>         ttm_bo_put()
> >>>> 	ttm_bo_release()
> >>>> 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
> >>>> 				     as second argument
> >>>> 	     *GPF*
> >>>>
> >>>> So, I've added check in ttm_bo_release() to avoid passing
> >>>> NULL as second argument to ttm_mem_io_free().
> >> Hi, Christian!
> >>
> >> Thank you for quick feedback :)
> >>
> >>> There is another ocassion of this a bit down before we call
> >>> ttm_bo_move_to_lru_tail() apart from that good catch.
> >>>
> >> Did you mean, that ttm_bo_move_to_lru_tail() should have NULL check
> >> too?
> 
> Yes, exactly that.
> 
> >>   I checked it's realization, and, I think, NULL check is necessary
> >> there, since mem pointer is dereferenced w/o any checking
> >>
> >>> But I'm wondering if we should make the functions NULL save
> >>> instead of the external check.
> >>>
> >> I tried to find more possible scenarios of GPF in ttm_bo_release(),
> >> but I didn't find one. But, yes, moving NULL check inside
> >> ttm_mem_io_free() is more general approach and it will defend this
> >> function from GPFs in the future.
> >>
> >>
> >>
> >> With regards,
> >> Pavel Skripkin
> >>
> > I misclicked and sent this email to Christian privately :(
> >
> > Added all thread participants back, sorry.
> 
> No problem.
> 
> Do you want to update your patch or should I take care of this?
> 

Yes, I will send v2 soon. Thank you!




With regards,
Pavel Skripkin

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [PATCH v2] gpu: ttm: add missing NULL checks
  2021-07-08 10:56         ` Christian König
@ 2021-07-08 11:25           ` Pavel Skripkin
  -1 siblings, 0 replies; 14+ messages in thread
From: Pavel Skripkin @ 2021-07-08 11:25 UTC (permalink / raw)
  To: christian.koenig, ray.huang, airlied
  Cc: dri-devel, linux-kernel, Pavel Skripkin

My local syzbot instance hit GPF in ttm_bo_release().
Unfortunately, syzbot didn't produce a reproducer for this, but I
found out possible scenario:

drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
				     (bo embedded in this object)
  ttm_bo_init()
    ttm_bo_init_reserved()
      ttm_resource_alloc()
        man->func->alloc()       <-- allocation failure
      ttm_bo_put()
	ttm_bo_release()
	  ttm_mem_io_free()      <-- bo->resource == NULL passed
				     as second argument
	     *GPF*

Added NULL check inside ttm_mem_io_free() to prevent reported GPF and
make this function NULL save in future.

Same problem was in ttm_bo_move_to_lru_tail() as Christian reported.
ttm_bo_move_to_lru_tail() is called in ttm_bo_release() and mem pointer
can be NULL as well as in ttm_mem_io_free().

Fail log:

KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66
Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f
RSP: 0018:ffffc900141df968 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90010da0000
RDX: 0000000000000004 RSI: ffffffff84513ea3 RDI: ffff888041fbc010
RBP: ffff888041fbc010 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000020 R14: ffff88806b258800 R15: ffff88806b258a38
FS:  00007fa6e9845640(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fad61265e18 CR3: 000000005ad79000 CR4: 0000000000350ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422
 kref_put include/linux/kref.h:65 [inline]
 ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline]
 ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050
 ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074
 drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228

Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
---

Changes in v2:
	1. Added NULL check in ttm_bo_move_to_lru_tail()
	
	2. Changed subject line, since NULL check added in 2 funtions

---
 drivers/gpu/drm/ttm/ttm_bo.c      | 3 +++
 drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1b950b45cf4b..8d7fd65ccced 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -102,6 +102,9 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
 		return;
 	}
 
+	if (!mem)
+		return;
+
 	man = ttm_manager_type(bdev, mem->mem_type);
 	list_move_tail(&bo->lru, &man->lru[bo->priority]);
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 2f57f824e6db..763fa6f4e07d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -63,6 +63,9 @@ int ttm_mem_io_reserve(struct ttm_device *bdev,
 void ttm_mem_io_free(struct ttm_device *bdev,
 		     struct ttm_resource *mem)
 {
+	if (!mem)
+		return;
+
 	if (!mem->bus.offset && !mem->bus.addr)
 		return;
 
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* [PATCH v2] gpu: ttm: add missing NULL checks
@ 2021-07-08 11:25           ` Pavel Skripkin
  0 siblings, 0 replies; 14+ messages in thread
From: Pavel Skripkin @ 2021-07-08 11:25 UTC (permalink / raw)
  To: christian.koenig, ray.huang, airlied
  Cc: Pavel Skripkin, linux-kernel, dri-devel

My local syzbot instance hit GPF in ttm_bo_release().
Unfortunately, syzbot didn't produce a reproducer for this, but I
found out possible scenario:

drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
				     (bo embedded in this object)
  ttm_bo_init()
    ttm_bo_init_reserved()
      ttm_resource_alloc()
        man->func->alloc()       <-- allocation failure
      ttm_bo_put()
	ttm_bo_release()
	  ttm_mem_io_free()      <-- bo->resource == NULL passed
				     as second argument
	     *GPF*

Added NULL check inside ttm_mem_io_free() to prevent reported GPF and
make this function NULL save in future.

Same problem was in ttm_bo_move_to_lru_tail() as Christian reported.
ttm_bo_move_to_lru_tail() is called in ttm_bo_release() and mem pointer
can be NULL as well as in ttm_mem_io_free().

Fail log:

KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66
Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f
RSP: 0018:ffffc900141df968 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90010da0000
RDX: 0000000000000004 RSI: ffffffff84513ea3 RDI: ffff888041fbc010
RBP: ffff888041fbc010 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000020 R14: ffff88806b258800 R15: ffff88806b258a38
FS:  00007fa6e9845640(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fad61265e18 CR3: 000000005ad79000 CR4: 0000000000350ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422
 kref_put include/linux/kref.h:65 [inline]
 ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline]
 ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050
 ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074
 drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228

Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
---

Changes in v2:
	1. Added NULL check in ttm_bo_move_to_lru_tail()
	
	2. Changed subject line, since NULL check added in 2 funtions

---
 drivers/gpu/drm/ttm/ttm_bo.c      | 3 +++
 drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1b950b45cf4b..8d7fd65ccced 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -102,6 +102,9 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
 		return;
 	}
 
+	if (!mem)
+		return;
+
 	man = ttm_manager_type(bdev, mem->mem_type);
 	list_move_tail(&bo->lru, &man->lru[bo->priority]);
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 2f57f824e6db..763fa6f4e07d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -63,6 +63,9 @@ int ttm_mem_io_reserve(struct ttm_device *bdev,
 void ttm_mem_io_free(struct ttm_device *bdev,
 		     struct ttm_resource *mem)
 {
+	if (!mem)
+		return;
+
 	if (!mem->bus.offset && !mem->bus.addr)
 		return;
 
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* Re: [PATCH v2] gpu: ttm: add missing NULL checks
  2021-07-08 11:25           ` Pavel Skripkin
@ 2021-07-08 11:29             ` Christian König
  -1 siblings, 0 replies; 14+ messages in thread
From: Christian König @ 2021-07-08 11:29 UTC (permalink / raw)
  To: Pavel Skripkin, ray.huang, airlied; +Cc: dri-devel, linux-kernel

Am 08.07.21 um 13:25 schrieb Pavel Skripkin:
> My local syzbot instance hit GPF in ttm_bo_release().
> Unfortunately, syzbot didn't produce a reproducer for this, but I
> found out possible scenario:
>
> drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
> 				     (bo embedded in this object)
>    ttm_bo_init()
>      ttm_bo_init_reserved()
>        ttm_resource_alloc()
>          man->func->alloc()       <-- allocation failure
>        ttm_bo_put()
> 	ttm_bo_release()
> 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
> 				     as second argument
> 	     *GPF*
>
> Added NULL check inside ttm_mem_io_free() to prevent reported GPF and
> make this function NULL save in future.
>
> Same problem was in ttm_bo_move_to_lru_tail() as Christian reported.
> ttm_bo_move_to_lru_tail() is called in ttm_bo_release() and mem pointer
> can be NULL as well as in ttm_mem_io_free().
>
> Fail log:
>
> KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
> CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
> RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66
> Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f
> RSP: 0018:ffffc900141df968 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90010da0000
> RDX: 0000000000000004 RSI: ffffffff84513ea3 RDI: ffff888041fbc010
> RBP: ffff888041fbc010 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
> R13: 0000000000000020 R14: ffff88806b258800 R15: ffff88806b258a38
> FS:  00007fa6e9845640(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fad61265e18 CR3: 000000005ad79000 CR4: 0000000000350ee0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422
>   kref_put include/linux/kref.h:65 [inline]
>   ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline]
>   ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050
>   ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074
>   drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228
>
> Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

Going to push this to drm-misc-next-fixes.

Thanks,
Christian.

> ---
>
> Changes in v2:
> 	1. Added NULL check in ttm_bo_move_to_lru_tail()
> 	
> 	2. Changed subject line, since NULL check added in 2 funtions
>
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c      | 3 +++
>   drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +++
>   2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 1b950b45cf4b..8d7fd65ccced 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -102,6 +102,9 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
>   		return;
>   	}
>   
> +	if (!mem)
> +		return;
> +
>   	man = ttm_manager_type(bdev, mem->mem_type);
>   	list_move_tail(&bo->lru, &man->lru[bo->priority]);
>   
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 2f57f824e6db..763fa6f4e07d 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -63,6 +63,9 @@ int ttm_mem_io_reserve(struct ttm_device *bdev,
>   void ttm_mem_io_free(struct ttm_device *bdev,
>   		     struct ttm_resource *mem)
>   {
> +	if (!mem)
> +		return;
> +
>   	if (!mem->bus.offset && !mem->bus.addr)
>   		return;
>   


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH v2] gpu: ttm: add missing NULL checks
@ 2021-07-08 11:29             ` Christian König
  0 siblings, 0 replies; 14+ messages in thread
From: Christian König @ 2021-07-08 11:29 UTC (permalink / raw)
  To: Pavel Skripkin, ray.huang, airlied; +Cc: linux-kernel, dri-devel

Am 08.07.21 um 13:25 schrieb Pavel Skripkin:
> My local syzbot instance hit GPF in ttm_bo_release().
> Unfortunately, syzbot didn't produce a reproducer for this, but I
> found out possible scenario:
>
> drm_gem_vram_create()            <-- drm_gem_vram_object kzalloced
> 				     (bo embedded in this object)
>    ttm_bo_init()
>      ttm_bo_init_reserved()
>        ttm_resource_alloc()
>          man->func->alloc()       <-- allocation failure
>        ttm_bo_put()
> 	ttm_bo_release()
> 	  ttm_mem_io_free()      <-- bo->resource == NULL passed
> 				     as second argument
> 	     *GPF*
>
> Added NULL check inside ttm_mem_io_free() to prevent reported GPF and
> make this function NULL save in future.
>
> Same problem was in ttm_bo_move_to_lru_tail() as Christian reported.
> ttm_bo_move_to_lru_tail() is called in ttm_bo_release() and mem pointer
> can be NULL as well as in ttm_mem_io_free().
>
> Fail log:
>
> KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
> CPU: 1 PID: 10419 Comm: syz-executor.3 Not tainted 5.13.0-rc7-next-20210625 #7
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
> RIP: 0010:ttm_mem_io_free+0x28/0x170 drivers/gpu/drm/ttm/ttm_bo_util.c:66
> Code: b1 90 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 e8 cd 19 24 fd 4c 8d 6b 20 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 2a 01 00 00 4c 8b 63 20 31 ff 4c 89 e6 e8 00 1f
> RSP: 0018:ffffc900141df968 EFLAGS: 00010202
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90010da0000
> RDX: 0000000000000004 RSI: ffffffff84513ea3 RDI: ffff888041fbc010
> RBP: ffff888041fbc010 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
> R13: 0000000000000020 R14: ffff88806b258800 R15: ffff88806b258a38
> FS:  00007fa6e9845640(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fad61265e18 CR3: 000000005ad79000 CR4: 0000000000350ee0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   ttm_bo_release+0xd94/0x10a0 drivers/gpu/drm/ttm/ttm_bo.c:422
>   kref_put include/linux/kref.h:65 [inline]
>   ttm_bo_put drivers/gpu/drm/ttm/ttm_bo.c:470 [inline]
>   ttm_bo_init_reserved+0x7cb/0x960 drivers/gpu/drm/ttm/ttm_bo.c:1050
>   ttm_bo_init+0x105/0x270 drivers/gpu/drm/ttm/ttm_bo.c:1074
>   drm_gem_vram_create+0x332/0x4c0 drivers/gpu/drm/drm_gem_vram_helper.c:228
>
> Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

Going to push this to drm-misc-next-fixes.

Thanks,
Christian.

> ---
>
> Changes in v2:
> 	1. Added NULL check in ttm_bo_move_to_lru_tail()
> 	
> 	2. Changed subject line, since NULL check added in 2 funtions
>
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c      | 3 +++
>   drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +++
>   2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 1b950b45cf4b..8d7fd65ccced 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -102,6 +102,9 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
>   		return;
>   	}
>   
> +	if (!mem)
> +		return;
> +
>   	man = ttm_manager_type(bdev, mem->mem_type);
>   	list_move_tail(&bo->lru, &man->lru[bo->priority]);
>   
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 2f57f824e6db..763fa6f4e07d 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -63,6 +63,9 @@ int ttm_mem_io_reserve(struct ttm_device *bdev,
>   void ttm_mem_io_free(struct ttm_device *bdev,
>   		     struct ttm_resource *mem)
>   {
> +	if (!mem)
> +		return;
> +
>   	if (!mem->bus.offset && !mem->bus.addr)
>   		return;
>   


^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-07-08 11:29 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-07 18:51 [PATCH] gpu: ttm: fix GPF in ttm_bo_release Pavel Skripkin
2021-07-07 18:51 ` Pavel Skripkin
2021-07-08  6:49 ` Christian König
2021-07-08  6:49   ` Christian König
     [not found]   ` <20210708113701.4cea7989@gmail.com>
2021-07-08 10:09     ` Pavel Skripkin
2021-07-08 10:09       ` Pavel Skripkin
2021-07-08 10:56       ` Christian König
2021-07-08 10:56         ` Christian König
2021-07-08 11:04         ` Pavel Skripkin
2021-07-08 11:04           ` Pavel Skripkin
2021-07-08 11:25         ` [PATCH v2] gpu: ttm: add missing NULL checks Pavel Skripkin
2021-07-08 11:25           ` Pavel Skripkin
2021-07-08 11:29           ` Christian König
2021-07-08 11:29             ` Christian König

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.