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.
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.
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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
