Re: [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 12 Nov 2020 at 02:27, Ruhl, Michael J <michael.j.ruhl@xxxxxxxxx> wrote:
>
> >-----Original Message-----
> >From: Thomas Zimmermann <tzimmermann@xxxxxxx>
> >Sent: Wednesday, November 11, 2020 7:08 AM
> >To: Ruhl, Michael J <michael.j.ruhl@xxxxxxxxx>; bskeggs@xxxxxxxxxx;
> >airlied@xxxxxxxx; daniel@xxxxxxxx; christian.koenig@xxxxxxx
> >Cc: nouveau@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx;
> >Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>; Maxime Ripard
> ><mripard@xxxxxxxxxx>; Dave Airlie <airlied@xxxxxxxxxx>; Gerd Hoffmann
> ><kraxel@xxxxxxxxxx>; Alex Deucher <alexander.deucher@xxxxxxx>;
> >VMware Graphics <linux-graphics-maintainer@xxxxxxxxxx>; Roland
> >Scheidegger <sroland@xxxxxxxxxx>; Huang Rui <ray.huang@xxxxxxx>;
> >Felix Kuehling <Felix.Kuehling@xxxxxxx>; Hawking Zhang
> ><Hawking.Zhang@xxxxxxx>; Jason Gunthorpe <jgg@xxxxxxxx>; Likun Gao
> ><Likun.Gao@xxxxxxx>; virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx; spice-
> >devel@xxxxxxxxxxxxxxxxxxxxx; amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> >Subject: Re: [PATCH] drm/nouveau: Fix out-of-bounds access when
> >deferencing MMU type
> >
> >Hi
> >
> >Am 10.11.20 um 16:27 schrieb Ruhl, Michael J:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Thomas Zimmermann <tzimmermann@xxxxxxx>
> >>> Sent: Tuesday, November 10, 2020 8:37 AM
> >>> To: bskeggs@xxxxxxxxxx; airlied@xxxxxxxx; daniel@xxxxxxxx; Ruhl, Michael J
> >>> <michael.j.ruhl@xxxxxxxxx>; christian.koenig@xxxxxxx
> >>> Cc: nouveau@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx;
> >Thomas
> >>> Zimmermann <tzimmermann@xxxxxxx>; Maarten Lankhorst
> >>> <maarten.lankhorst@xxxxxxxxxxxxxxx>; Maxime Ripard
> >>> <mripard@xxxxxxxxxx>; Dave Airlie <airlied@xxxxxxxxxx>; Gerd Hoffmann
> >>> <kraxel@xxxxxxxxxx>; Alex Deucher <alexander.deucher@xxxxxxx>;
> >>> VMware Graphics <linux-graphics-maintainer@xxxxxxxxxx>; Roland
> >>> Scheidegger <sroland@xxxxxxxxxx>; Huang Rui <ray.huang@xxxxxxx>;
> >>> Felix Kuehling <Felix.Kuehling@xxxxxxx>; Hawking Zhang
> >>> <Hawking.Zhang@xxxxxxx>; Jason Gunthorpe <jgg@xxxxxxxx>; Likun
> >Gao
> >>> <Likun.Gao@xxxxxxx>; virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx; spice-
> >>> devel@xxxxxxxxxxxxxxxxxxxxx; amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> >>> Subject: [PATCH] drm/nouveau: Fix out-of-bounds access when
> >deferencing
> >>> MMU type
> >>>
> >>> The value of struct drm_device.ttm.type_vram can become -1 for
> >unknown
> >>> types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds
> >>> error when accessing struct nvif_mmu.type[]:
> >>
> >> Would this make more sense to just set the type_vram = 0 instead of -1?
> >
> >From what I understand, these indices refer to an internal type of MMU,
> >rsp the MMU's capabilities. However, my hardware (pre-NV50) does not
> >have an MMU at all.
>
> Yeah, and upon further review I see that my comment was completely wrong
> (value vs. index).
>
> A better suggestion would have been, create an entry in the array that means,
> "unsupported type" with a value of 0, but...
>
> >I agree that it would be nice to have a cleaner design that incorporates
> >this case, but resolving that would apparently require more than a bugfix.
>
> I agree.  The -1 index is a special case for the platform path
> (platform != NV_DEVICE_INFO_V0_SOC).  This is a fix for the issue, but not
> a complete solution.
>
> If you need it:
> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@xxxxxxxxx>
I've put an alternate fix for this here[1], and will get it into
drm-fixes later today.

Ben.

[1] https://github.com/skeggsb/nouveau/commit/4590f7120c2f1f4aea9d8b93a2dae43b312d35ad

>
> Thanks,
> Mike
>
> >Best regards
> >Thomas
> >
> >>
> >> Mike
> >>
> >>>
> >>>  [   18.304116]
> >>>
> >===========================================================
> >>> =======
> >>>  [   18.311649] BUG: KASAN: slab-out-of-bounds in
> >>> nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> >>>  [   18.320415] Read of size 1 at addr ffff88810ffac1fe by task systemd-
> >>> udevd/342
> >>>  [   18.327681]
> >>>  [   18.329208] CPU: 1 PID: 342 Comm: systemd-udevd Tainted: G            E
> >>> 5.10.0-rc2-1-default+ #581
> >>>  [   18.338681] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
> >>> 10/24/2018
> >>>  [   18.346032] Call Trace:
> >>>  [   18.348536]  dump_stack+0xae/0xe5
> >>>  [   18.351919]  print_address_description.constprop.0+0x17/0xf0
> >>>  [   18.357787]  ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> >>>  [   18.363818]  __kasan_report.cold+0x20/0x38
> >>>  [   18.368099]  ? nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> >>>  [   18.374133]  kasan_report+0x3a/0x50
> >>>  [   18.377789]  nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau]
> >>>  <...>
> >>>  [   18.767690] Allocated by task 342:
> >>>  [   18.773087]  kasan_save_stack+0x1b/0x40
> >>>  [   18.778890]  __kasan_kmalloc.constprop.0+0xbf/0xd0
> >>>  [   18.785646]  __kmalloc_track_caller+0x1be/0x390
> >>>  [   18.792165]  kstrdup_const+0x46/0x70
> >>>  [   18.797686]  kobject_set_name_vargs+0x2f/0xb0
> >>>  [   18.803992]  kobject_init_and_add+0x9d/0xf0
> >>>  [   18.810117]  ttm_mem_global_init+0x12c/0x210 [ttm]
> >>>  [   18.816853]  ttm_bo_global_init+0x4a/0x160 [ttm]
> >>>  [   18.823420]  ttm_bo_device_init+0x39/0x220 [ttm]
> >>>  [   18.830046]  nouveau_ttm_init+0x2c3/0x830 [nouveau]
> >>>  [   18.836929]  nouveau_drm_device_init+0x1b4/0x3f0 [nouveau]
> >>>  <...>
> >>>  [   19.105336]
> >>>
> >===========================================================
> >>> =======
> >>>
> >>> Fix this error, by not using type_vram as an index if it's negative.
> >>> Assume default values instead.
> >>>
> >>> The error was seen on Nvidia G72 hardware.
> >>>
> >>> Signed-off-by: Thomas Zimmermann <tzimmermann@xxxxxxx>
> >>> Fixes: 1cf65c45183a ("drm/ttm: add caching state to ttm_bus_placement")
> >>> Cc: Christian König <christian.koenig@xxxxxxx>
> >>> Cc: Michael J. Ruhl <michael.j.ruhl@xxxxxxxxx>
> >>> Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
> >>> Cc: Maxime Ripard <mripard@xxxxxxxxxx>
> >>> Cc: Thomas Zimmermann <tzimmermann@xxxxxxx>
> >>> Cc: David Airlie <airlied@xxxxxxxx>
> >>> Cc: Daniel Vetter <daniel@xxxxxxxx>
> >>> Cc: Ben Skeggs <bskeggs@xxxxxxxxxx>
> >>> Cc: Dave Airlie <airlied@xxxxxxxxxx>
> >>> Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx>
> >>> Cc: Alex Deucher <alexander.deucher@xxxxxxx>
> >>> Cc: "Christian König" <christian.koenig@xxxxxxx>
> >>> Cc: VMware Graphics <linux-graphics-maintainer@xxxxxxxxxx>
> >>> Cc: Roland Scheidegger <sroland@xxxxxxxxxx>
> >>> Cc: Huang Rui <ray.huang@xxxxxxx>
> >>> Cc: Felix Kuehling <Felix.Kuehling@xxxxxxx>
> >>> Cc: Hawking Zhang <Hawking.Zhang@xxxxxxx>
> >>> Cc: Jason Gunthorpe <jgg@xxxxxxxx>
> >>> Cc: Likun Gao <Likun.Gao@xxxxxxx>
> >>> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
> >>> Cc: nouveau@xxxxxxxxxxxxxxxxxxxxx
> >>> Cc: virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
> >>> Cc: spice-devel@xxxxxxxxxxxxxxxxxxxxx
> >>> Cc: amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> >>> ---
> >>> drivers/gpu/drm/nouveau/nouveau_bo.c | 5 ++++-
> >>> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> index 8133377d865d..fe15299d417e 100644
> >>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> @@ -1142,9 +1142,12 @@ nouveau_ttm_io_mem_reserve(struct
> >>> ttm_bo_device *bdev, struct ttm_resource *reg)
> >>>     struct nvkm_device *device = nvxx_device(&drm->client.device);
> >>>     struct nouveau_mem *mem = nouveau_mem(reg);
> >>>     struct nvif_mmu *mmu = &drm->client.mmu;
> >>> -   const u8 type = mmu->type[drm->ttm.type_vram].type;
> >>> +   u8 type = 0;
> >>>     int ret;
> >>>
> >>> +   if (drm->ttm.type_vram >= 0)
> >>> +           type = mmu->type[drm->ttm.type_vram].type;
> >>> +
> >>>     mutex_lock(&drm->ttm.io_reserve_mutex);
> >>> retry:
> >>>     switch (reg->mem_type) {
> >>> --
> >>> 2.29.2
> >>
> >
> >--
> >Thomas Zimmermann
> >Graphics Driver Developer
> >SUSE Software Solutions Germany GmbH
> >Maxfeldstr. 5, 90409 Nürnberg, Germany
> >(HRB 36809, AG Nürnberg)
> >Geschäftsführer: Felix Imendörffer
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux