linux-kernel - Re: [PATCH] drm/vc4: Fix atomicity violation in vc4_crtc_send

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: <ZvKNVut_V9fiiaaT@phenom.ffwll.local>
Date: Tue, 24 Sep 2024 11:58:46 +0200
From: Simona Vetter <simona.vetter@...ll.ch>
To: Qiu-ji Chen <chenqiuji666@...il.com>
Cc: mripard@...nel.org, dave.stevenson@...pberrypi.com,
	kernel-list@...pberrypi.com, maarten.lankhorst@...ux.intel.com,
	tzimmermann@...e.de, airlied@...il.com, daniel@...ll.ch,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	baijiaju1990@...il.com, stable@...r.kernel.org
Subject: Re: [PATCH] drm/vc4: Fix atomicity violation in
 vc4_crtc_send_vblank()

On Fri, Sep 13, 2024 at 05:10:53PM +0800, Qiu-ji Chen wrote:
> Atomicity violation occurs when the vc4_crtc_send_vblank function is
> executed simultaneously with modifications to crtc->state or
> crtc->state->event. Consider a scenario where both crtc->state and
> crtc->state->event are non-null. They can pass the validity check, but at
> the same time, crtc->state or crtc->state->event could be set to null. In
> this case, the validity check in vc4_crtc_send_vblank might act on the old
> crtc->state and crtc->state->event (before locking), allowing invalid
> values to pass the validity check, leading to null pointer dereference.
> 
> To address this issue, it is recommended to include the validity check of
> crtc->state and crtc->state->event within the locking section of the
> function. This modification ensures that the values of crtc->state->event
> and crtc->state do not change during the validation process, maintaining
> their valid conditions.
> 
> This possible bug is found by an experimental static analysis tool
> developed by our team. This tool analyzes the locking APIs
> to extract function pairs that can be concurrently executed, and then
> analyzes the instructions in the paired functions to identify possible
> concurrency bugs including data races and atomicity violations.
> 
> Fixes: 68e4a69aec4d ("drm/vc4: crtc: Create vblank reporting function")
> Cc: stable@...r.kernel.org
> Signed-off-by: Qiu-ji Chen <chenqiuji666@...il.com>
> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 8b5a7e5eb146..98885f519827 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -575,10 +575,12 @@ void vc4_crtc_send_vblank(struct drm_crtc *crtc)
>  	struct drm_device *dev = crtc->dev;
>  	unsigned long flags;
>  
> -	if (!crtc->state || !crtc->state->event)
> +	spin_lock_irqsave(&dev->event_lock, flags);

crtc->state isn't protected by this spinlock, which also points at the
more fundamental bug here: We need to pass the crtc_state from the caller,
because those have it (or well, can look it up with
drm_atomic_get_new_crtc_state). Then we also do not need a spinlock to
protect access to state->event, because in both callers we are the owners
of this struct field.
-Sima

> +	if (!crtc->state || !crtc->state->event) {
> +		spin_unlock_irqrestore(&dev->event_lock, flags);
>  		return;
> +	}
>  
> -	spin_lock_irqsave(&dev->event_lock, flags);
>  	drm_crtc_send_vblank_event(crtc, crtc->state->event);
>  	crtc->state->event = NULL;
>  	spin_unlock_irqrestore(&dev->event_lock, flags);
> -- 
> 2.34.1
> 

-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch