linux-kernel - Re: [PATCH] drm/gud: fix NULL fb and crtc dereferences on USB disconnect

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <938b5e8e-b849-4d12-8ee2-98312094fc1e@shenghaoyang.info>
Date: Sun, 4 Jan 2026 01:47:58 +0800
From: Shenghao Yang <me@...nghaoyang.info>
To: Ruben Wauters <rubenru09@....com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH] drm/gud: fix NULL fb and crtc dereferences on USB
 disconnect

Hi Ruben,

On 4/1/26 01:23, Ruben Wauters wrote:

> With the elimination of these two WARN_ON_ONCEs, it's possible that
> crtc_state may not be assigned below, and therefore may be read/passed
> to functions when it is NULL (e.g. line 488). Either protection for a
> null crtc_state should be added to the rest of the function, or the
> function shouldn't continue if crtc is NULL.
> 
> Ruben
>> -	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
>> -
>> -	mode = &crtc_state->mode;
>> +	if (crtc)
>> +		crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
>>  
>>  	ret = drm_atomic_helper_check_plane_state(new_plane_state, crtc_state,
>>  						  DRM_PLANE_NO_SCALING,
>> @@ -492,6 +485,9 @@ int gud_plane_atomic_check(struct drm_plane *plane,
>>  	if (old_plane_state->rotation != new_plane_state->rotation)
>>  		crtc_state->mode_changed = true;
>>  
>> +	mode = &crtc_state->mode;
>> +	format = fb->format;

Yup - in this case I'm relying on drm_atomic_helper_check_plane_state()
bailing out early after seeing that fb is NULL (since a NULL crtc should
imply no fb) and setting plane_state->visible to false.

That would cause an early return in gud_plane_atomic_check() without
dereferencing crtc_state.

Would a more explicit check be preferred?

Thanks,

Shenghao