[PATCH v2 0/3] nouveau: fix 3 null-ptr derefs

[PATCH v2 0/3] nouveau: fix 3 null-ptr derefs

[Jim Cromie via B4 Relay]

These 3 patches fix NULL ptr derefs I hit while booting kernels with
unrelated work (dynamic-debug) on a 2019 amdgpu+noueau laptop.  One of
them is possibly hard to reproduce, the others are "dependable".

Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
Changes in v2:
- added check of gsp->rm into nvkm_gsp_rm(gsp)
- change if-then-else to if-early-fail, fallthru
- Link to v1: https://lore.kernel.org/r/20261002-my-fixups-v1-0-a83d20f9d3fe@gmail.com

---
Jim Cromie (3):
      nouveau: Fix NULL pointer dereferences in GETPARAM ioctl
      nouveau: Fix NULL pointer dereference in GET_ZCULL_INFO ioctl
      nouveau: Fix NULL dereference in nvkm_gsp_gcx_ready()

 drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h |  2 +-
 drivers/gpu/drm/nouveau/nouveau_abi16.c           | 24 ++++++++++++++++++++---
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c |  2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c    |  2 +-
 4 files changed, 24 insertions(+), 6 deletions(-)
---
base-commit: 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e
change-id: 20261002-my-fixups-324d25f3bd05

Best regards,
-- 
Jim Cromie <jim.cromie@gmail.com>

[PATCH v2 1/3] nouveau: Fix NULL pointer dereferences in GETPARAM ioctl

[Jim Cromie via B4 Relay]

From: Jim Cromie <jim.cromie@gmail.com>

When hardware or firmware initialization fails, the graphics engine
(gr) or device functions may remain NULL. Attempting to access these
during the GETPARAM ioctl (e.g., NOUVEAU_GETPARAM_GRAPH_UNITS) results
in a kernel NULL pointer dereference, causing a crash when userspace
(GNOME/Mesa) attempts to probe the device.

Add safety checks for 'gr', 'gr->func', and 'nvkm_device->func' in the
ioctl handler. Return -ENODEV to signal the missing hardware state to
userspace, and use NV_ERROR_ONCE to provide diagnostic proof in the
kernel log without risking a console flood.

NOTE:

I encountered these crashes while booting unrelated code (in
dynamic-debug) on real HW.  There was also some fwupd updates around
this time, so it could all be transient/unreproducible.  But it did
happen, and could happen again in unforseen circumstances.

@Capitain_Jack tested the error path in v1 by deleting the FW

Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Tested-by: Daniel Campos Ramos <Capitain_Jack@yahoo.com>
---
 drivers/gpu/drm/nouveau/nouveau_abi16.c | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 4542d5f4ded8..3f130cd4fbcd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -306,6 +306,11 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
 		getparam->value = 1;
 		break;
 	case NOUVEAU_GETPARAM_GRAPH_UNITS:
+		if (!gr || !gr->func) {
+			NV_ERROR_ONCE(drm, "GETPARAM_GRAPH_UNITS: no gr engine or func\n");
+			return -ENODEV;
+		}
+
 		getparam->value = nvkm_gr_units(gr);
 		break;
 	case NOUVEAU_GETPARAM_EXEC_PUSH_MAX: {
@@ -315,10 +320,23 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
 		break;
 	}
 	case NOUVEAU_GETPARAM_VRAM_BAR_SIZE:
-		getparam->value = nvkm_device->func->resource_size(nvkm_device, NVKM_BAR1_FB);
+		if (!nvkm_device || !nvkm_device->func || !nvkm_device->func->resource_size) {
+			NV_ERROR_ONCE(drm, "GETPARAM_VRAM_BAR_SIZE: no device func\n");
+			return -ENODEV;
+		}
+
+		getparam->value =
+			nvkm_device->func->resource_size(nvkm_device, NVKM_BAR1_FB);
 		break;
 	case NOUVEAU_GETPARAM_VRAM_USED: {
-		struct ttm_resource_manager *vram_mgr = ttm_manager_type(&drm->ttm.bdev, TTM_PL_VRAM);
+		struct ttm_resource_manager *vram_mgr =
+			ttm_manager_type(&drm->ttm.bdev, TTM_PL_VRAM);
+
+		if (!vram_mgr) {
+			NV_ERROR_ONCE(drm, "GETPARAM_VRAM_USED: no vram mgr\n");
+			return -ENODEV;
+		}
+
 		getparam->value = (u64)ttm_resource_manager_usage(vram_mgr);
 		break;
 	}

-- 
2.56.0

[PATCH v2 2/3] nouveau: Fix NULL pointer dereference in GET_ZCULL_INFO ioctl

[Jim Cromie via B4 Relay]

From: Jim Cromie <jim.cromie@gmail.com>

When graphics engine firmware fails to load or initialization aborts
early, nvxx_gr(drm) returns NULL. Calling DRM_IOCTL_NOUVEAU_GET_ZCULL_INFO
causes nouveau_abi16_ioctl_get_zcull_info() to dereference gr at offset
0xf0 without checking for NULL, triggering a kernel page fault.

Validate that gr is non-NULL before inspecting gr->has_zcull_info.

Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
Aug 14 09:21:52 frodo kernel: BUG: kernel NULL pointer dereference, address: 00000000000000f0
Aug 14 09:21:52 frodo kernel: #PF: error_code(0x0000) - not-present page
Aug 14 09:21:52 frodo kernel: Oops: Oops: 0000 [#1] SMP NOPTI
Aug 14 09:21:52 frodo kernel: RIP: 0010:nouveau_abi16_ioctl_get_zcull_info+0x17/0xa0 [nouveau]
Aug 14 09:21:52 frodo kernel: Code: 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 47 40 48 8b 00 48 8b 80 70 02 00 00 <80> b8 f0 00 00 00 00 74 72 8b 90 c0 00 00 00 89 16 8b 90 c4 00 00
Aug 14 09:21:52 frodo kernel: Call Trace:
Aug 14 09:21:52 frodo kernel:  <TASK>
Aug 14 09:21:52 frodo kernel:  drm_ioctl_kernel+0xae/0x100
Aug 14 09:21:52 frodo kernel:  drm_ioctl+0x2e0/0x560
Aug 14 09:21:52 frodo kernel:  ? __pfx_nouveau_abi16_ioctl_get_zcull_info+0x10/0x10 [nouveau]
Aug 14 09:21:52 frodo kernel:  nouveau_drm_ioctl+0x58/0xc0 [nouveau]
Aug 14 09:21:52 frodo kernel:  __x64_sys_ioctl+0xb9/0x100
Aug 14 09:21:52 frodo kernel:  do_syscall_64+0xe2/0x560
Aug 14 09:21:52 frodo kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
Aug 14 09:21:52 frodo kernel:  </TASK>

Reviewed-by: Lyude Paul <lyude@redhat.com>
Tested-by: Daniel Campos Ramos <Capitain_Jack@yahoo.com>
---
 drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 3f130cd4fbcd..c7ddc54a3c4d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -358,7 +358,7 @@ nouveau_abi16_ioctl_get_zcull_info(ABI16_IOCTL_ARGS)
 	struct nvkm_gr *gr = nvxx_gr(drm);
 	struct drm_nouveau_get_zcull_info *out = data;
 
-	if (gr->has_zcull_info) {
+	if (gr && gr->has_zcull_info) {
 		const struct nvkm_gr_zcull_info *i = &gr->zcull_info;
 
 		out->width_align_pixels = i->width_align_pixels;

-- 
2.56.0

[PATCH v2 3/3] nouveau: Fix NULL dereference in nvkm_gsp_gcx_ready()

[Jim Cromie via B4 Relay]

From: Jim Cromie <jim.cromie@gmail.com>

Commit cb4c7603678c ("drm/nouveau/gsp/r570: Add support for
INTERNAL_GCX_ENTRY_PREREQUISITE") hooked nvif_device_gcx_ready() into
nouveau_pmops_runtime_suspend() to consult GSP before runtime suspend.

On GPUs running without GSP-RM (e.g. Volta GV100, NvGspRm=0, or missing
GSP firmware blobs), device->gsp is instantiated but gsp->rm remains
NULL. nvkm_udevice_gcx_ready() checked "!gsp" instead of verifying
nvkm_gsp_rm(gsp), allowing non-RM instances to invoke
nvkm_gsp_gcx_ready(). nvkm_gsp_gcx_ready() then unconditionally
dereferenced gsp->rm->api, causing a kernel oops:

  RIP: 0010:nvkm_gsp_gcx_ready+0x10/0x30 [nouveau]
  Code: ... 48 8b 87 70 0e 00 00 <48> 8b 40 18 ...
  RAX: 0000000000000000 RDI: ffff8c9555fca000
  Call Trace:
   nvkm_udevice_mthd+0xa5/0x150 [nouveau]
   nvkm_ioctl+0xcc/0x1d0 [nouveau]
   nvif_object_mthd+0x110/0x1e0 [nouveau]
   nvif_device_gcx_ready+0x36/0x60 [nouveau]
   nouveau_pmops_runtime_suspend+0x39/0x140 [nouveau]

Instruction decode shows `mov rax, [rdi+0xe70]` loads gsp->rm (0x0),
and `<48> 8b 40 18` (`mov rax, [rax+0x18]`) faults accessing rm->api.

Fix by:
0. Checking !nvkm_gsp_rm(gsp) in nvkm_udevice_gcx_ready() so non-RM
   devices report GC6/GcOff ready and bypass the GSP call entirely.
1. Guarding gsp and gsp->rm in nvkm_gsp_gcx_ready() before inspecting
   gsp->rm->api->gsp->gcx_ready.

Fixes: cb4c7603678c ("drm/nouveau/gsp/r570: Add support for INTERNAL_GCX_ENTRY_PREREQUISITE")
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
 drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c    | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
index ed5c6e0e68d3..933f13ed2a50 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
@@ -274,7 +274,7 @@ struct nvkm_gsp {
 static inline bool
 nvkm_gsp_rm(struct nvkm_gsp *gsp)
 {
-	return gsp && (gsp->fws.rm || gsp->fw.img);
+	return gsp && gsp->rm && (gsp->fws.rm || gsp->fw.img);
 }
 
 #include <rm/rm.h>
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
index f78e6b9b4292..d469437eb991 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
@@ -201,7 +201,7 @@ nvkm_udevice_gcx_ready(struct nvkm_udevice *udev, void *data, u32 size)
 	} *args = data;
 	int ret = -ENOSYS;
 
-	if (!gsp) {
+	if (!nvkm_gsp_rm(gsp)) {
 		args->v0.ready = NV_DEVICE_GC6_READY | NV_DEVICE_GCOFF_READY;
 		return 0;
 	}
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
index e475d0e8fa7b..ea895f04293a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
@@ -51,7 +51,7 @@ nvkm_gsp_intr_stall(struct nvkm_gsp *gsp, enum nvkm_subdev_type type, int inst)
 int
 nvkm_gsp_gcx_ready(struct nvkm_gsp *gsp)
 {
-	if (!gsp->rm->api->gsp->gcx_ready)
+	if (!nvkm_gsp_rm(gsp) || !gsp->rm->api->gsp->gcx_ready)
 		return NV_DEVICE_GC6_READY | NV_DEVICE_GCOFF_READY;
 
 	return gsp->rm->api->gsp->gcx_ready(gsp);

-- 
2.56.0

Re: [PATCH v2 1/3] nouveau: Fix NULL pointer dereferences in GETPARAM ioctl

[lyude]

On Fri, 2026-10-09 at 11:44 -0600, Jim Cromie via B4 Relay wrote:
> From: Jim Cromie <jim.cromie@gmail.com>
> 
> When hardware or firmware initialization fails, the graphics engine
> (gr) or device functions may remain NULL. Attempting to access these
> during the GETPARAM ioctl (e.g., NOUVEAU_GETPARAM_GRAPH_UNITS)
> results
> in a kernel NULL pointer dereference, causing a crash when userspace
> (GNOME/Mesa) attempts to probe the device.
> 
> Add safety checks for 'gr', 'gr->func', and 'nvkm_device->func' in
> the
> ioctl handler. Return -ENODEV to signal the missing hardware state to
> userspace, and use NV_ERROR_ONCE to provide diagnostic proof in the
> kernel log without risking a console flood.
> 
> NOTE:
> 
> I encountered these crashes while booting unrelated code (in
> dynamic-debug) on real HW.  There was also some fwupd updates around
> this time, so it could all be transient/unreproducible.  But it did
> happen, and could happen again in unforseen circumstances.
> 
> @Capitain_Jack tested the error path in v1 by deleting the FW

I can just fix this up before pushing but JFYI - if you put comments
below the --- that's down below, they will show up in the email but not
the commit message.

Either way -

Reviewed-by: Lyude Paul <lyude@redhat.com>

> 
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> Tested-by: Daniel Campos Ramos <Capitain_Jack@yahoo.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_abi16.c | 22 ++++++++++++++++++++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> index 4542d5f4ded8..3f130cd4fbcd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> @@ -306,6 +306,11 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
>  		getparam->value = 1;
>  		break;
>  	case NOUVEAU_GETPARAM_GRAPH_UNITS:
> +		if (!gr || !gr->func) {
> +			NV_ERROR_ONCE(drm, "GETPARAM_GRAPH_UNITS: no
> gr engine or func\n");
> +			return -ENODEV;
> +		}
> +
>  		getparam->value = nvkm_gr_units(gr);
>  		break;
>  	case NOUVEAU_GETPARAM_EXEC_PUSH_MAX: {
> @@ -315,10 +320,23 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
>  		break;
>  	}
>  	case NOUVEAU_GETPARAM_VRAM_BAR_SIZE:
> -		getparam->value = nvkm_device->func-
> >resource_size(nvkm_device, NVKM_BAR1_FB);
> +		if (!nvkm_device || !nvkm_device->func ||
> !nvkm_device->func->resource_size) {
> +			NV_ERROR_ONCE(drm, "GETPARAM_VRAM_BAR_SIZE:
> no device func\n");
> +			return -ENODEV;
> +		}
> +
> +		getparam->value =
> +			nvkm_device->func-
> >resource_size(nvkm_device, NVKM_BAR1_FB);
>  		break;
>  	case NOUVEAU_GETPARAM_VRAM_USED: {
> -		struct ttm_resource_manager *vram_mgr =
> ttm_manager_type(&drm->ttm.bdev, TTM_PL_VRAM);
> +		struct ttm_resource_manager *vram_mgr =
> +			ttm_manager_type(&drm->ttm.bdev,
> TTM_PL_VRAM);
> +
> +		if (!vram_mgr) {
> +			NV_ERROR_ONCE(drm, "GETPARAM_VRAM_USED: no
> vram mgr\n");
> +			return -ENODEV;
> +		}
> +
>  		getparam->value =
> (u64)ttm_resource_manager_usage(vram_mgr);
>  		break;
>  	}

Re: [PATCH v2 2/3] nouveau: Fix NULL pointer dereference in GET_ZCULL_INFO ioctl

[lyude]

Just for patchwork's sake, since the tags got stuck below the ---

Reviewed-by: Lyude Paul <lyude@redhat.com>

On Fri, 2026-10-09 at 11:44 -0600, Jim Cromie via B4 Relay wrote:
> From: Jim Cromie <jim.cromie@gmail.com>
> 
> When graphics engine firmware fails to load or initialization aborts
> early, nvxx_gr(drm) returns NULL. Calling
> DRM_IOCTL_NOUVEAU_GET_ZCULL_INFO
> causes nouveau_abi16_ioctl_get_zcull_info() to dereference gr at
> offset
> 0xf0 without checking for NULL, triggering a kernel page fault.
> 
> Validate that gr is non-NULL before inspecting gr->has_zcull_info.
> 
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> ---
> Aug 14 09:21:52 frodo kernel: BUG: kernel NULL pointer dereference,
> address: 00000000000000f0
> Aug 14 09:21:52 frodo kernel: #PF: error_code(0x0000) - not-present
> page
> Aug 14 09:21:52 frodo kernel: Oops: Oops: 0000 [#1] SMP NOPTI
> Aug 14 09:21:52 frodo kernel: RIP:
> 0010:nouveau_abi16_ioctl_get_zcull_info+0x17/0xa0 [nouveau]
> Aug 14 09:21:52 frodo kernel: Code: 00 00 00 90 90 90 90 90 90 90 90
> 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 47 40 48 8b
> 00 48 8b 80 70 02 00 00 <80> b8 f0 00 00 00 00 74 72 8b 90 c0 00 00
> 00 89 16 8b 90 c4 00 00
> Aug 14 09:21:52 frodo kernel: Call Trace:
> Aug 14 09:21:52 frodo kernel:  <TASK>
> Aug 14 09:21:52 frodo kernel:  drm_ioctl_kernel+0xae/0x100
> Aug 14 09:21:52 frodo kernel:  drm_ioctl+0x2e0/0x560
> Aug 14 09:21:52 frodo kernel:  ?
> __pfx_nouveau_abi16_ioctl_get_zcull_info+0x10/0x10 [nouveau]
> Aug 14 09:21:52 frodo kernel:  nouveau_drm_ioctl+0x58/0xc0 [nouveau]
> Aug 14 09:21:52 frodo kernel:  __x64_sys_ioctl+0xb9/0x100
> Aug 14 09:21:52 frodo kernel:  do_syscall_64+0xe2/0x560
> Aug 14 09:21:52 frodo kernel: 
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
> Aug 14 09:21:52 frodo kernel:  </TASK>
> 
> Reviewed-by: Lyude Paul <lyude@redhat.com>
> Tested-by: Daniel Campos Ramos <Capitain_Jack@yahoo.com>
> ---
>  drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> index 3f130cd4fbcd..c7ddc54a3c4d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> @@ -358,7 +358,7 @@
> nouveau_abi16_ioctl_get_zcull_info(ABI16_IOCTL_ARGS)
>  	struct nvkm_gr *gr = nvxx_gr(drm);
>  	struct drm_nouveau_get_zcull_info *out = data;
>  
> -	if (gr->has_zcull_info) {
> +	if (gr && gr->has_zcull_info) {
>  		const struct nvkm_gr_zcull_info *i = &gr-
> >zcull_info;
>  
>  		out->width_align_pixels = i->width_align_pixels;

Re: [PATCH v2 3/3] nouveau: Fix NULL dereference in nvkm_gsp_gcx_ready()

[lyude]

Reviewed-by: Lyude Paul <lyude@redhat.com>

On Fri, 2026-10-09 at 11:44 -0600, Jim Cromie via B4 Relay wrote:
> From: Jim Cromie <jim.cromie@gmail.com>
> 
> Commit cb4c7603678c ("drm/nouveau/gsp/r570: Add support for
> INTERNAL_GCX_ENTRY_PREREQUISITE") hooked nvif_device_gcx_ready() into
> nouveau_pmops_runtime_suspend() to consult GSP before runtime
> suspend.
> 
> On GPUs running without GSP-RM (e.g. Volta GV100, NvGspRm=0, or
> missing
> GSP firmware blobs), device->gsp is instantiated but gsp->rm remains
> NULL. nvkm_udevice_gcx_ready() checked "!gsp" instead of verifying
> nvkm_gsp_rm(gsp), allowing non-RM instances to invoke
> nvkm_gsp_gcx_ready(). nvkm_gsp_gcx_ready() then unconditionally
> dereferenced gsp->rm->api, causing a kernel oops:
> 
>   RIP: 0010:nvkm_gsp_gcx_ready+0x10/0x30 [nouveau]
>   Code: ... 48 8b 87 70 0e 00 00 <48> 8b 40 18 ...
>   RAX: 0000000000000000 RDI: ffff8c9555fca000
>   Call Trace:
>    nvkm_udevice_mthd+0xa5/0x150 [nouveau]
>    nvkm_ioctl+0xcc/0x1d0 [nouveau]
>    nvif_object_mthd+0x110/0x1e0 [nouveau]
>    nvif_device_gcx_ready+0x36/0x60 [nouveau]
>    nouveau_pmops_runtime_suspend+0x39/0x140 [nouveau]
> 
> Instruction decode shows `mov rax, [rdi+0xe70]` loads gsp->rm (0x0),
> and `<48> 8b 40 18` (`mov rax, [rax+0x18]`) faults accessing rm->api.
> 
> Fix by:
> 0. Checking !nvkm_gsp_rm(gsp) in nvkm_udevice_gcx_ready() so non-RM
>    devices report GC6/GcOff ready and bypass the GSP call entirely.
> 1. Guarding gsp and gsp->rm in nvkm_gsp_gcx_ready() before inspecting
>    gsp->rm->api->gsp->gcx_ready.
> 
> Fixes: cb4c7603678c ("drm/nouveau/gsp/r570: Add support for
> INTERNAL_GCX_ENTRY_PREREQUISITE")
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> ---
>  drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 2 +-
>  drivers/gpu/drm/nouveau/nvkm/engine/device/user.c | 2 +-
>  drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c    | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
> index ed5c6e0e68d3..933f13ed2a50 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
> @@ -274,7 +274,7 @@ struct nvkm_gsp {
>  static inline bool
>  nvkm_gsp_rm(struct nvkm_gsp *gsp)
>  {
> -	return gsp && (gsp->fws.rm || gsp->fw.img);
> +	return gsp && gsp->rm && (gsp->fws.rm || gsp->fw.img);
>  }
>  
>  #include <rm/rm.h>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
> index f78e6b9b4292..d469437eb991 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
> @@ -201,7 +201,7 @@ nvkm_udevice_gcx_ready(struct nvkm_udevice *udev,
> void *data, u32 size)
>  	} *args = data;
>  	int ret = -ENOSYS;
>  
> -	if (!gsp) {
> +	if (!nvkm_gsp_rm(gsp)) {
>  		args->v0.ready = NV_DEVICE_GC6_READY |
> NV_DEVICE_GCOFF_READY;
>  		return 0;
>  	}
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
> index e475d0e8fa7b..ea895f04293a 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
> @@ -51,7 +51,7 @@ nvkm_gsp_intr_stall(struct nvkm_gsp *gsp, enum
> nvkm_subdev_type type, int inst)
>  int
>  nvkm_gsp_gcx_ready(struct nvkm_gsp *gsp)
>  {
> -	if (!gsp->rm->api->gsp->gcx_ready)
> +	if (!nvkm_gsp_rm(gsp) || !gsp->rm->api->gsp->gcx_ready)
>  		return NV_DEVICE_GC6_READY | NV_DEVICE_GCOFF_READY;
>  
>  	return gsp->rm->api->gsp->gcx_ready(gsp);

Re: [PATCH v2 1/3] nouveau: Fix NULL pointer dereferences in GETPARAM ioctl

[Danilo Krummrich]

On Fri Oct 9, 2026 at 7:44 PM CEST, Jim Cromie via B4 Relay wrote:
> From: Jim Cromie <jim.cromie@gmail.com>
>
> When hardware or firmware initialization fails, the graphics engine
> (gr) or device functions may remain NULL. Attempting to access these
> during the GETPARAM ioctl (e.g., NOUVEAU_GETPARAM_GRAPH_UNITS) results
> in a kernel NULL pointer dereference, causing a crash when userspace
> (GNOME/Mesa) attempts to probe the device.
>
> Add safety checks for 'gr', 'gr->func', and 'nvkm_device->func' in the
> ioctl handler. Return -ENODEV to signal the missing hardware state to
> userspace, and use NV_ERROR_ONCE to provide diagnostic proof in the
> kernel log without risking a console flood.
>
> NOTE:
>
> I encountered these crashes while booting unrelated code (in
> dynamic-debug) on real HW.  There was also some fwupd updates around
> this time, so it could all be transient/unreproducible.  But it did
> happen, and could happen again in unforseen circumstances.
>
> @Capitain_Jack tested the error path in v1 by deleting the FW
>
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> Tested-by: Daniel Campos Ramos <Capitain_Jack@yahoo.com>

Do they need to be separate patches? Do we need a Fixes: tag? Why not CC stable?

> ---
>  drivers/gpu/drm/nouveau/nouveau_abi16.c | 22 ++++++++++++++++++++--
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> index 4542d5f4ded8..3f130cd4fbcd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> @@ -306,6 +306,11 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
>  		getparam->value = 1;
>  		break;
>  	case NOUVEAU_GETPARAM_GRAPH_UNITS:
> +		if (!gr || !gr->func) {
> +			NV_ERROR_ONCE(drm, "GETPARAM_GRAPH_UNITS: no gr engine or func\n");
> +			return -ENODEV;
> +		}
> +
>  		getparam->value = nvkm_gr_units(gr);
>  		break;
>  	case NOUVEAU_GETPARAM_EXEC_PUSH_MAX: {
> @@ -315,10 +320,23 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
>  		break;
>  	}
>  	case NOUVEAU_GETPARAM_VRAM_BAR_SIZE:
> -		getparam->value = nvkm_device->func->resource_size(nvkm_device, NVKM_BAR1_FB);
> +		if (!nvkm_device || !nvkm_device->func || !nvkm_device->func->resource_size) {

How can any of those ever be NULL?

> +			NV_ERROR_ONCE(drm, "GETPARAM_VRAM_BAR_SIZE: no device func\n");
> +			return -ENODEV;
> +		}
> +
> +		getparam->value =
> +			nvkm_device->func->resource_size(nvkm_device, NVKM_BAR1_FB);
>  		break;
>  	case NOUVEAU_GETPARAM_VRAM_USED: {
> -		struct ttm_resource_manager *vram_mgr = ttm_manager_type(&drm->ttm.bdev, TTM_PL_VRAM);
> +		struct ttm_resource_manager *vram_mgr =
> +			ttm_manager_type(&drm->ttm.bdev, TTM_PL_VRAM);
> +
> +		if (!vram_mgr) {

Same here, how can this ever be NULL?

> +			NV_ERROR_ONCE(drm, "GETPARAM_VRAM_USED: no vram mgr\n");
> +			return -ENODEV;
> +		}
> +
>  		getparam->value = (u64)ttm_resource_manager_usage(vram_mgr);
>  		break;
>  	}
>
> -- 
> 2.56.0

Re: [PATCH v2 2/3] nouveau: Fix NULL pointer dereference in GET_ZCULL_INFO ioctl

[Danilo Krummrich]

On Fri Oct 9, 2026 at 7:44 PM CEST, Jim Cromie via B4 Relay wrote:
> From: Jim Cromie <jim.cromie@gmail.com>
>
> When graphics engine firmware fails to load or initialization aborts
> early, nvxx_gr(drm) returns NULL. Calling DRM_IOCTL_NOUVEAU_GET_ZCULL_INFO
> causes nouveau_abi16_ioctl_get_zcull_info() to dereference gr at offset
> 0xf0 without checking for NULL, triggering a kernel page fault.
>
> Validate that gr is non-NULL before inspecting gr->has_zcull_info.
>
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>

Please add a Fixes: tag and CC stable.

Re: [PATCH v2 3/3] nouveau: Fix NULL dereference in nvkm_gsp_gcx_ready()

[Danilo Krummrich]

On Fri Oct 9, 2026 at 7:44 PM CEST, Jim Cromie via B4 Relay wrote:
> From: Jim Cromie <jim.cromie@gmail.com>
>
> Commit cb4c7603678c ("drm/nouveau/gsp/r570: Add support for
> INTERNAL_GCX_ENTRY_PREREQUISITE") hooked nvif_device_gcx_ready() into
> nouveau_pmops_runtime_suspend() to consult GSP before runtime suspend.
>
> On GPUs running without GSP-RM (e.g. Volta GV100, NvGspRm=0, or missing
> GSP firmware blobs), device->gsp is instantiated but gsp->rm remains
> NULL. nvkm_udevice_gcx_ready() checked "!gsp" instead of verifying
> nvkm_gsp_rm(gsp), allowing non-RM instances to invoke
> nvkm_gsp_gcx_ready(). nvkm_gsp_gcx_ready() then unconditionally
> dereferenced gsp->rm->api, causing a kernel oops:
>
>   RIP: 0010:nvkm_gsp_gcx_ready+0x10/0x30 [nouveau]
>   Code: ... 48 8b 87 70 0e 00 00 <48> 8b 40 18 ...
>   RAX: 0000000000000000 RDI: ffff8c9555fca000
>   Call Trace:
>    nvkm_udevice_mthd+0xa5/0x150 [nouveau]
>    nvkm_ioctl+0xcc/0x1d0 [nouveau]
>    nvif_object_mthd+0x110/0x1e0 [nouveau]
>    nvif_device_gcx_ready+0x36/0x60 [nouveau]
>    nouveau_pmops_runtime_suspend+0x39/0x140 [nouveau]
>
> Instruction decode shows `mov rax, [rdi+0xe70]` loads gsp->rm (0x0),
> and `<48> 8b 40 18` (`mov rax, [rax+0x18]`) faults accessing rm->api.
>
> Fix by:
> 0. Checking !nvkm_gsp_rm(gsp) in nvkm_udevice_gcx_ready() so non-RM
>    devices report GC6/GcOff ready and bypass the GSP call entirely.
> 1. Guarding gsp and gsp->rm in nvkm_gsp_gcx_ready() before inspecting
>    gsp->rm->api->gsp->gcx_ready.
>
> Fixes: cb4c7603678c ("drm/nouveau/gsp/r570: Add support for INTERNAL_GCX_ENTRY_PREREQUISITE")
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>

Isn't this fixed in commit 4d0e27041185 ("nouveau: check gsp->rm as well as gsp
pointer before gcx ready") already?

Re: [PATCH v2 3/3] nouveau: Fix NULL dereference in nvkm_gsp_gcx_ready()

[lyude]

On Fri, 2026-10-09 at 23:53 +0200, Danilo Krummrich wrote:
> On Fri Oct 9, 2026 at 7:44 PM CEST, Jim Cromie via B4 Relay wrote:
> > From: Jim Cromie <jim.cromie@gmail.com>
> > 
> > Commit cb4c7603678c ("drm/nouveau/gsp/r570: Add support for
> > INTERNAL_GCX_ENTRY_PREREQUISITE") hooked nvif_device_gcx_ready()
> > into
> > nouveau_pmops_runtime_suspend() to consult GSP before runtime
> > suspend.
> > 
> > On GPUs running without GSP-RM (e.g. Volta GV100, NvGspRm=0, or
> > missing
> > GSP firmware blobs), device->gsp is instantiated but gsp->rm
> > remains
> > NULL. nvkm_udevice_gcx_ready() checked "!gsp" instead of verifying
> > nvkm_gsp_rm(gsp), allowing non-RM instances to invoke
> > nvkm_gsp_gcx_ready(). nvkm_gsp_gcx_ready() then unconditionally
> > dereferenced gsp->rm->api, causing a kernel oops:
> > 
> >   RIP: 0010:nvkm_gsp_gcx_ready+0x10/0x30 [nouveau]
> >   Code: ... 48 8b 87 70 0e 00 00 <48> 8b 40 18 ...
> >   RAX: 0000000000000000 RDI: ffff8c9555fca000
> >   Call Trace:
> >    nvkm_udevice_mthd+0xa5/0x150 [nouveau]
> >    nvkm_ioctl+0xcc/0x1d0 [nouveau]
> >    nvif_object_mthd+0x110/0x1e0 [nouveau]
> >    nvif_device_gcx_ready+0x36/0x60 [nouveau]
> >    nouveau_pmops_runtime_suspend+0x39/0x140 [nouveau]
> > 
> > Instruction decode shows `mov rax, [rdi+0xe70]` loads gsp->rm
> > (0x0),
> > and `<48> 8b 40 18` (`mov rax, [rax+0x18]`) faults accessing rm-
> > >api.
> > 
> > Fix by:
> > 0. Checking !nvkm_gsp_rm(gsp) in nvkm_udevice_gcx_ready() so non-RM
> >    devices report GC6/GcOff ready and bypass the GSP call entirely.
> > 1. Guarding gsp and gsp->rm in nvkm_gsp_gcx_ready() before
> > inspecting
> >    gsp->rm->api->gsp->gcx_ready.
> > 
> > Fixes: cb4c7603678c ("drm/nouveau/gsp/r570: Add support for
> > INTERNAL_GCX_ENTRY_PREREQUISITE")
> > Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> 
> Isn't this fixed in commit 4d0e27041185 ("nouveau: check gsp->rm as
> well as gsp
> pointer before gcx ready") already?

(gonna hold off on pushing all 3 of these patches, you're right - I
completely forgot that we had already pushed a commit for this)