search for: nvif_mmu

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[]: [ 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] [...

...ns(+), 22 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvif/if0008.h b/drivers/gpu/drm/nouveau/include/nvif/if0008.h index 8450127420f5..c21d09f04f1d 100644 --- a/drivers/gpu/drm/nouveau/include/nvif/if0008.h +++ b/drivers/gpu/drm/nouveau/include/nvif/if0008.h @@ -35,7 +35,7 @@ struct nvif_mmu_type_v0 { struct nvif_mmu_kind_v0 { __u8 version; - __u8 pad01[1]; + __u8 kind_inv; __u16 count; __u8 data[]; }; diff --git a/drivers/gpu/drm/nouveau/include/nvif/mmu.h b/drivers/gpu/drm/nouveau/include/nvif/mmu.h index 747ecf67e403..cec1e88a0a05 100644 --- a/drivers/gpu/drm/nouveau/i...

...ouveau/nvif/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvif/mmu.c b/drivers/gpu/drm/nouveau/nvif/mmu.c index ae08a1ca8044..5641bda2046d 100644 --- a/drivers/gpu/drm/nouveau/nvif/mmu.c +++ b/drivers/gpu/drm/nouveau/nvif/mmu.c @@ -110,7 +110,7 @@ nvif_mmu_init(struct nvif_object *parent, s32 oclass, struct nvif_mmu *mmu) if (mmu->kind_nr) { struct nvif_mmu_kind_v0 *kind; - u32 argc = sizeof(*kind) + sizeof(*kind->data) * mmu->kind_nr; + size_t argc = struct_size(kind, data, mmu->kind_nr); if (ret = -ENOMEM, !(kind = kmalloc...

...; 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...

...include <linux/swiotlb.h> #include <drm/ttm/ttm_range_manager.h> +#include <drm/drm_cache.h> #include "nouveau_drv.h" #include "nouveau_gem.h" @@ -265,7 +265,6 @@ nouveau_ttm_init(struct nouveau_drm *drm) struct nvkm_pci *pci = device->pci; struct nvif_mmu *mmu = &drm->client.mmu; struct drm_device *dev = drm->dev; - bool need_swiotlb = false; int typei, ret; ret = nouveau_ttm_init_host(drm, 0); @@ -300,13 +299,10 @@ nouveau_ttm_init(struct nouveau_drm *drm) drm->agp.cma = pci->agp.cma; } -#if IS_ENABLED(CONFIG_SWIOTLB)...

...lists.freedesktop.org >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? Mike > > [ 18.304116] >=========================================================== >======= > [ 18.311649] BUG: KASAN: slab-out-of-bounds in >nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] &...

...gt; >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 M...

...au: 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 fur...

...>>> 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 no...

One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct nvif_mmu_kind_v0 { ... __u8 data[]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. So, replace the following form: sizeof(*kind) + sizeof(*kind->data) * mmu->kind_nr with: struct_size(kind, data, mmu->kind_nr)...

Hi all, this little series removes the last swiotlb API exposed to modules. Diffstat: arch/x86/include/asm/xen/swiotlb-xen.h | 6 ------ arch/x86/kernel/pci-dma.c | 28 ++++------------------------ drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++------- drivers/pci/xen-pcifront.c | 6 ------ kernel/dma/swiotlb.c | 1 - 5 files changed, 7

...RASTER_COMPLETE; + case NV50_CRC_SOURCE_OUTP_INACTIVE: + return NV50_CRC_RASTER_INACTIVE; + } + + return 0; +} + +/* We handle mapping the memory for CRC notifiers ourselves, since each + * notifier needs it's own handle + */ +static inline int +nv50_crc_ctx_init(struct nv50_head *head, struct nvif_mmu *mmu, + struct nv50_crc_notifier_ctx *ctx, size_t len, int idx) +{ + struct nv50_core *core = nv50_disp(head->base.base.dev)->core; + int ret; + + ret = nvif_mem_init_map(mmu, NVIF_MEM_VRAM, len, &ctx->mem); + if (ret) + return ret; + + ret = nvif_object_init(&core->chan.bas...

...RASTER_COMPLETE; + case NV50_CRC_SOURCE_OUTP_INACTIVE: + return NV50_CRC_RASTER_INACTIVE; + } + + return 0; +} + +/* We handle mapping the memory for CRC notifiers ourselves, since each + * notifier needs it's own handle + */ +static inline int +nv50_crc_ctx_init(struct nv50_head *head, struct nvif_mmu *mmu, + struct nv50_crc_notifier_ctx *ctx, size_t len, int idx) +{ + struct nv50_core *core = nv50_disp(head->base.base.dev)->core; + int ret; + + ret = nvif_mem_init_map(mmu, NVIF_MEM_VRAM, len, &ctx->mem); + if (ret) + return ret; + + ret = nvif_object_init(&core->chan.bas...

...RASTER_COMPLETE; + case NV50_CRC_SOURCE_OUTP_INACTIVE: + return NV50_CRC_RASTER_INACTIVE; + } + + return 0; +} + +/* We handle mapping the memory for CRC notifiers ourselves, since each + * notifier needs it's own handle + */ +static inline int +nv50_crc_ctx_init(struct nv50_head *head, struct nvif_mmu *mmu, + struct nv50_crc_notifier_ctx *ctx, size_t len, int idx) +{ + struct nv50_core *core = nv50_disp(head->base.base.dev)->core; + int ret; + + ret = nvif_mem_init_map(mmu, NVIF_MEM_VRAM, len, &ctx->mem); + if (ret) + return ret; + + ret = nvif_object_init(&core->chan.bas...

...RASTER_COMPLETE; + case NV50_CRC_SOURCE_OUTP_INACTIVE: + return NV50_CRC_RASTER_INACTIVE; + } + + return 0; +} + +/* We handle mapping the memory for CRC notifiers ourselves, since each + * notifier needs it's own handle + */ +static inline int +nv50_crc_ctx_init(struct nv50_head *head, struct nvif_mmu *mmu, + struct nv50_crc_notifier_ctx *ctx, size_t len, int idx) +{ + struct nv50_core *core = nv50_disp(head->base.base.dev)->core; + int ret; + + ret = nvif_mem_init_map(mmu, NVIF_MEM_VRAM, len, &ctx->mem); + if (ret) + return ret; + + ret = nvif_object_init(&core->chan.bas...

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Hi folks, Currently, when the device is removed (or the driver is unbound) the nouveau_drm structure de-allocated. However, it's still accessible from and used by some DRM layer callbacks. For example, file handles can be closed after the device has been removed (physically or otherwise). This series converts the Nouveau device structure to be allocated and de-allocated with the