Re: [PATCH v10 12/69] drm/bridge: Fix unlocked list_del in drm_bridge_add()
[email protected] Fri, 31 Jul 2026 17:50:16 +0000
| Newsgroups | dev.linux.lists.linux-sunxi,org.freedesktop.lists.dri-devel |
|---|---|
| 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