Re: [PATCH v10 12/69] drm/bridge: Fix unlocked list_del in drm_bridge_add()

[email protected]
Newsgroups org.freedesktop.lists.dri-devel,dev.linux.lists.linux-sunxi
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Legacy zero-initialized bridges not allocated via devm_drm_bridge_alloc() will cause a kernel panic due to an uninitialized list_head and trigger refcount warnings.
--

--- Patch [12]: [PATCH v10 12/69] drm/bridge: Fix unlocked list_del in drm_bridge_add() ---
commit e0f10da4c05d8a75c537ce94edb147bda1eb2e78
Author: Cristian Ciocaltea <[email protected]>

drm/bridge: Fix unlocked list_del in drm_bridge_add()

This commit addresses a list corruption issue in drm_bridge_add() by wrapping 
the bridge_lingering_list removal sequence with the bridge_lock mutex. It 
prevents concurrent modifications from drm_bridge_remove() and debugfs walks.

Closes: https://lore.kernel.org/all/[email protected]/

> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index afaae272347c0..8b8f71c3ccff9 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c

[ ... ]

> @@ -454,8 +455,10 @@ void drm_bridge_add(struct drm_bridge *bridge)
>  	 * in bridge_lingering_list. Remove it or bridge_lingering_list will be
>  	 * corrupted when adding this bridge to bridge_list below.
>  	 */
> -	if (!list_empty(&bridge->list))
> -		list_del_init(&bridge->list);
> +	scoped_guard(mutex, &bridge_lock) {
> +		if (!list_empty(&bridge->list))
> +			list_del_init(&bridge->list);
> +	}

[Severity: High]
This is a pre-existing issue, but will this cause a kernel panic for legacy 
bridge drivers that allocate struct drm_bridge using kzalloc() instead of 
devm_drm_bridge_alloc()?

For a zero-initialized bridge struct, the list_empty() check evaluates to 
false because the uninitialized list_head pointers are NULL, and NULL is not 
equal to &bridge->list. 

This means list_del_init() will execute and unconditionally dereference the 
NULL prev and next pointers, crashing the kernel during device probe.

Is it possible to check if the list_head is actually initialized before 
testing if it is empty, or handle legacy zero-initialized bridges safely 
to avoid breaking the probe path on affected platforms?

>  
>  	mutex_init(&bridge->hpd_state_mutex);
>  	mutex_init(&bridge->hpd_mutex);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=12
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.