linux-kernel - Re: [PATCH] drm/i2c/ch7006: fix a possible null pointer dereference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2346aa93e2479f2ebd8849c5b2ead36a50ce43a0.camel@redhat.com>
Date:   Mon, 09 Oct 2023 17:45:48 -0400
From:   Lyude Paul <lyude@...hat.com>
To:     Ma Ke <make_ruc2021@....com>, airlied@...il.com, daniel@...ll.ch,
        javierm@...hat.com, mripard@...nel.org,
        u.kleine-koenig@...gutronix.de, noralf@...nnes.org,
        tzimmermann@...e.de
Cc:     dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/i2c/ch7006: fix a possible null pointer dereference

On Sat, 2023-10-07 at 11:17 +0800, Ma Ke wrote:
> In ch7006_encoder_get_modes(), the return value of drm_mode_duplicate()
> is assigned to mode, which will lead to a NULL pointer dereference
> on failure of drm_mode_duplicate(). Add a check to avoid npd.
> 
> Signed-off-by: Ma Ke <make_ruc2021@....com>
> ---
>  drivers/gpu/drm/i2c/ch7006_drv.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
> index 131512a5f3bd..27c2f02f5b43 100644
> --- a/drivers/gpu/drm/i2c/ch7006_drv.c
> +++ b/drivers/gpu/drm/i2c/ch7006_drv.c
> @@ -236,8 +236,10 @@ static int ch7006_encoder_get_modes(struct drm_encoder *encoder,
>  		    ~mode->valid_norms & 1<<priv->norm)
>  			continue;
>  
> -		drm_mode_probed_add(connector,
> -				drm_mode_duplicate(encoder->dev, &mode->mode));
> +		struct drm_display_mode *encoder_mode;
> +		encoder_mode = drm_mode_duplicate(encoder->dev, &mode->mode);

I think the kernel prefers to have variable declaration at the top of the
scope, and as well: this breaks things because you don't add back the
drm_mode_probed_add() call.

> +		if (!mode)
> +			continue;
>  
>  		n++;
>  	}

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat