Re: [PATCH v3 3/5] nouveau/gsp/rm/alloc: Cleanup IS_ERR_OR_NULL usage

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Double fetch of `rpc->length` from untrusted GSP shared memory allows bypassing size validation and causing a heap buffer overflow.
- [Critical] Integer underflow in `r535_gsp_msgq_recv_one_elem()` when copying continuation records with a small length.
- [Critical] Missing validation of continuation chunk sizes in `r535_gsp_msgq_recv()` leads to heap buffer overflow and integer underflow.
- [High] Silent failure when GSP firmware sends a corrupted RPC reply for an allocation request.
- [High] Memory leak of the RPC reply payload when `nvkm_gsp_rpc_wr()` is used with `NVKM_GSP_RPC_REPLY_RECV`.
- [High] Large RPC message buffer leak on error paths in `r535_gsp_rpc_push()`.
--

commit 80c014f86c2f1ac065ff1b0e24d2eb0c508a2e4a
Author: Hongling Zeng <zenghongling@kylinos.cn>

nouveau/gsp/rm/alloc: Cleanup IS_ERR_OR_NULL usage

This commit cleans up the usage of IS_ERR_OR_NULL in r535_gsp_rpc_rm_free().
It updates the check for nvkm_gsp_rpc_get() to only use IS_ERR(), matching
its actual return value contract.

> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c
> index 46e3a29f2ad7f..c9f86c0e9b255 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c
> @@ -35,7 +35,7 @@ r535_gsp_rpc_rm_free(struct nvkm_gsp_object *object)
>  		   client->object.handle, object->handle);
>  
>  	rpc = nvkm_gsp_rpc_get(gsp, NV_VGPU_MSG_FUNCTION_FREE, sizeof(*rpc));
> -	if (WARN_ON(IS_ERR_OR_NULL(rpc)))
> +	if (WARN_ON(IS_ERR(rpc)))
>  		return -EIO;
>  
>  	rpc->params.hRoot = client->object.handle;
>  	rpc->params.hObjectParent = 0;
>  	rpc->params.hObjectOld = object->handle;
>  	return nvkm_gsp_rpc_wr(gsp, rpc, NVKM_GSP_RPC_REPLY_RECV);

[Severity: High]
This is a pre-existing issue, but I noticed nvkm_gsp_rpc_wr() returns 0 on
success and drops the reply buffer allocated by nvkm_gsp_rpc_push().

When nvkm_gsp_rpc_wr() is called with NVKM_GSP_RPC_REPLY_RECV, the reply
is returned via:

drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h:nvkm_gsp_rpc_wr() {
    ...
    void *repv = nvkm_gsp_rpc_push(gsp, argv, policy, 0);

    if (IS_ERR(repv))
        return PTR_ERR(repv);

    return 0;
}

Since the caller here doesn't receive the reply buffer, and nvkm_gsp_rpc_wr()
doesn't free it, does this leak memory every time r535_gsp_rpc_rm_free()
is called?

[Severity: High]
This isn't a bug introduced by this patch, but looking at the error
handling for RPCs, I see that r535_gsp_rpc_rm_alloc_push() can return NULL:

drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c:r535_gsp_rpc_rm_alloc_push() {
    ...
    if (IS_ERR_OR_NULL(rpc))
        return rpc;
    ...
}

However, nvkm_gsp_rm_alloc_wr() only checks for IS_ERR(repv) and then
returns 0 (success) if it is not an error:

drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h:nvkm_gsp_rm_alloc_wr() {
    ...
    if (IS_ERR(repv))
        return PTR_ERR(repv);

    return 0;
}

Since IS_ERR() evaluates to false for NULL, does this incorrectly mask
failures and treat them as successful allocations?

[Severity: High]
This is a pre-existing issue, but in r535_gsp_rpc_push(), if the final
reply yields an error, the code skips kvfree(msg):

drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:r535_gsp_rpc_push() {
    ...
    repv = r535_gsp_rpc_handle_reply(gsp, fn, policy, payload_size +
                                     sizeof(*rpc));
    if (!IS_ERR(repv))
        kvfree(msg);
    ...
}

If an error occurs or the code branches to the done label, does this leak
the large RPC message buffer?

[Severity: Critical]
This isn't a bug introduced by this patch, but looking at
r535_gsp_msgq_recv(), the length is read from shared memory directly:

drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:r535_gsp_msgq_recv() {
    ...
    if (WARN_ON(rpc->length > max_rpc_size))
        return NULL;

    buf = kvmalloc(max_t(u32, rpc->length, expected), GFP_KERNEL);
    ...
    info.gsp_rpc_len = rpc->length;
}

Since the length is read again after kvmalloc(), which acts as a compiler
barrier, can the GSP firmware change rpc->length between the validation
and the second fetch, bypassing the size check?

[Severity: Critical]
This is a pre-existing issue, but in r535_gsp_msgq_recv_one_elem(), there
is a size calculation without validation:

drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:r535_gsp_msgq_recv_one_elem() {
    ...
    if (info->continuation)
        memcpy(buf, mqe->data + sizeof(struct nvfw_gsp_rpc),
               len - sizeof(struct nvfw_gsp_rpc));
}

If the provided length is smaller than sizeof(struct nvfw_gsp_rpc), will
this underflow and copy an excessive amount of data out-of-bounds?

[Severity: Critical]
This isn't a bug introduced by this patch, but when processing multi-part
messages in r535_gsp_msgq_recv(), the code subtracts chunk size from expected
without validation:

drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:r535_gsp_msgq_recv() {
    ...
    size = info.gsp_rpc_len - sizeof(*rpc);
    expected -= size;
    info.gsp_rpc_buf += size;
}

If size is larger than the remaining expected amount, does expected underflow
and cause the buffer pointer to advance out of bounds on subsequent chunks?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622021207.14764-1-zenghongling@kylinos.cn?part=3