From: Hongling Zeng <zhongling0719@126.com>
To: Danilo Krummrich <dakr@kernel.org>,
Hongling Zeng <zenghongling@kylinos.cn>
Cc: lyude@redhat.com, maarten.lankhorst@linux.intel.com,
mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
simona@ffwll.ch, airlied@redhat.com, ttabi@nvidia.com,
bskeggs@nvidia.com, dri-devel@lists.freedesktop.org,
nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nouveau/gsp: fix NULL pointer dereference in r535 nvenc/ofs alloc
Date: Wed, 27 May 2026 09:56:33 +0800 [thread overview]
Message-ID: <6A164F51.7010203@126.com> (raw)
In-Reply-To: <DISMY2BS8E1D.Q85V8DKCPM1C@kernel.org>
Hi Danilo,
Thank you for the feedback. You're right.
After tracing through the call chain:
nvkm_gsp_rm_alloc_get()
└─> r535_gsp_rpc_rm_alloc_get()
└─> r535_gsp_rpc_get()
└─> r535_gsp_cmdq_get()
└─> kvzalloc()
r535_gsp_cmdq_get() returns ERR_PTR(-ENOMEM)
on allocation failure, not NULL. So NULL is never actually returned.
I found a similar issue in sunrpc where IS_ERR_OR_NULL() is actively
harmful -
PTR_ERR(NULL) would return 0 (EOF), masking real errors. This
confirms the pattern
you identified.
Should I submit a patch to clean up the IS_ERR_OR_NULL() checks in:
- nvkm_gsp_rm_alloc_get() / nvkm_gsp_rm_alloc()
- nvkm_gsp_rpc_rd()
- All the callers
Or would you prefer to handle this differently?
Regards,
Hongling
在 2026年05月26日 21:16, Danilo Krummrich 写道:
> On Tue May 26, 2026 at 3:47 AM CEST, Hongling Zeng wrote:
>> nvkm_gsp_rm_alloc_get() can return NULL as well as error pointers.
>> The current code only checks for error pointers with IS_ERR(), which
>> would lead to a NULL pointer dereference if NULL is returned.
>>
>> Fix by using IS_ERR_OR_NULL() instead of IS_ERR(), matching the
>> pattern used in nvkm_gsp_rm_alloc().
> There was a similar patch [1] a while ago for another callsite. I replied:
>
> Are we sure that this can ever return NULL in the first place? I know
> that nvkm_gsp_rm_alloc_get() internally checks for IS_ERR_OR_NULL(), but
> I couldn't find anything within the callchain that would actually return
> NULL.
>
> That said, I think IS_ERR_OR_NULL() checks are misleading.
>
> Is there a real case where NULL can be returned? If not, let's remove the
> IS_ERR_OR_NULL() throughout the whole chain instead.
>
> [1] https://lore.kernel.org/lkml/20260418071412.86022-1-sunliming@linux.dev/
WARNING: multiple messages have this Message-ID (diff)
From: Hongling Zeng <zhongling0719@126.com>
To: Danilo Krummrich <dakr@kernel.org>,
Hongling Zeng <zenghongling@kylinos.cn>
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
simona@ffwll.ch, airlied@redhat.com, bskeggs@nvidia.com,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nouveau/gsp: fix NULL pointer dereference in r535 nvenc/ofs alloc
Date: Wed, 27 May 2026 09:56:33 +0800 [thread overview]
Message-ID: <6A164F51.7010203@126.com> (raw)
In-Reply-To: <DISMY2BS8E1D.Q85V8DKCPM1C@kernel.org>
Hi Danilo,
Thank you for the feedback. You're right.
After tracing through the call chain:
nvkm_gsp_rm_alloc_get()
└─> r535_gsp_rpc_rm_alloc_get()
└─> r535_gsp_rpc_get()
└─> r535_gsp_cmdq_get()
└─> kvzalloc()
r535_gsp_cmdq_get() returns ERR_PTR(-ENOMEM)
on allocation failure, not NULL. So NULL is never actually returned.
I found a similar issue in sunrpc where IS_ERR_OR_NULL() is actively
harmful -
PTR_ERR(NULL) would return 0 (EOF), masking real errors. This
confirms the pattern
you identified.
Should I submit a patch to clean up the IS_ERR_OR_NULL() checks in:
- nvkm_gsp_rm_alloc_get() / nvkm_gsp_rm_alloc()
- nvkm_gsp_rpc_rd()
- All the callers
Or would you prefer to handle this differently?
Regards,
Hongling
在 2026年05月26日 21:16, Danilo Krummrich 写道:
> On Tue May 26, 2026 at 3:47 AM CEST, Hongling Zeng wrote:
>> nvkm_gsp_rm_alloc_get() can return NULL as well as error pointers.
>> The current code only checks for error pointers with IS_ERR(), which
>> would lead to a NULL pointer dereference if NULL is returned.
>>
>> Fix by using IS_ERR_OR_NULL() instead of IS_ERR(), matching the
>> pattern used in nvkm_gsp_rm_alloc().
> There was a similar patch [1] a while ago for another callsite. I replied:
>
> Are we sure that this can ever return NULL in the first place? I know
> that nvkm_gsp_rm_alloc_get() internally checks for IS_ERR_OR_NULL(), but
> I couldn't find anything within the callchain that would actually return
> NULL.
>
> That said, I think IS_ERR_OR_NULL() checks are misleading.
>
> Is there a real case where NULL can be returned? If not, let's remove the
> IS_ERR_OR_NULL() throughout the whole chain instead.
>
> [1] https://lore.kernel.org/lkml/20260418071412.86022-1-sunliming@linux.dev/
next prev parent reply other threads:[~2026-05-27 1:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 1:47 [PATCH] nouveau/gsp: fix NULL pointer dereference in r535 nvenc/ofs alloc Hongling Zeng
2026-05-26 13:16 ` Danilo Krummrich
2026-05-26 13:16 ` Danilo Krummrich
2026-05-27 1:56 ` Hongling Zeng [this message]
2026-05-27 1:56 ` Hongling Zeng
2026-05-27 10:39 ` Danilo Krummrich
2026-05-27 10:39 ` Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6A164F51.7010203@126.com \
--to=zhongling0719@126.com \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=bskeggs@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=simona@ffwll.ch \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.de \
--cc=zenghongling@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.