lkml.org 
[lkml]   [2024]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] drm/i915/gt: Prevent possible NULL dereference in __caps_show()
From

Hi,

On 06/02/2024 16:45, Nikita Zhandarovich wrote:
> After falling through the switch statement to default case 'repr' is
> initialized with NULL, which will lead to incorrect dereference of
> '!repr[n]' in the following loop.
>
> Fix it with the help of an additional check for NULL.
>
> Found by Linux Verification Center (linuxtesting.org) with static
> analysis tool SVACE.
>
> Fixes: 4ec76dbeb62b ("drm/i915/gt: Expose engine properties via sysfs")
> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
> ---
> P.S. The NULL-deref problem might be dealt with this way but I am
> not certain that the rest of the __caps_show() behaviour remains
> correct if we end up in default case. For instance, as far as I
> can tell, buf might turn out to be w/o '\0'. I could use some
> direction if this has to be addressed as well.
>
> drivers/gpu/drm/i915/gt/sysfs_engines.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/sysfs_engines.c b/drivers/gpu/drm/i915/gt/sysfs_engines.c
> index 021f51d9b456..6b130b732867 100644
> --- a/drivers/gpu/drm/i915/gt/sysfs_engines.c
> +++ b/drivers/gpu/drm/i915/gt/sysfs_engines.c
> @@ -105,7 +105,7 @@ __caps_show(struct intel_engine_cs *engine,
>
> len = 0;
> for_each_set_bit(n, &caps, show_unknown ? BITS_PER_LONG : count) {
> - if (n >= count || !repr[n]) {
> + if (n >= count || !repr || !repr[n]) {

There are two input combinations to this function when repr is NULL.

First is show_unknown=true and caps=0, which means the for_each_set_bit
will not execute its body. (No bits set.)

Second is show_unknown=false and caps=~0, which means count is zero so
for_each_set_bit will again not run. (Bitfield size input param is zero.)

So unless I am missing something I do not see the null pointer dereference.

What could theoretically happen is that a third input combination
appears, where caps is not zero in the show_unknown=true case, either
via a fully un-handled engine->class (switch), or a new capability bit
not added to the static array a bit above.

That would assert during driver development here:

if (GEM_WARN_ON(show_unknown))

Granted that could be after the dereference in "if (n >= count ||
!repr[n])", but would be caught in debug builds (CI) and therefore not
be able to "ship" (get merge to the repo).

Your second question is about empty buffer returned i.e. len=0 at the
end of the function? (Which is when the buffer will not be null
terminated - or you see another option?)

That I think is safe too since it just results in a zero length read in
sysfs.

Regards,

Tvrtko

> if (GEM_WARN_ON(show_unknown))
> len += sysfs_emit_at(buf, len, "[%x] ", n);
> } else {

\
 
 \ /
  Last update: 2024-05-27 14:51    [W:0.065 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site