The DisplayPort AUX channel gets initialized and registered during
dw_dp_bind(), but it is never unregistered, which may lead to resource
leaks and/or use-after-free:
[ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0
[ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658
...
[ 224.662796] device_is_dependent+0xe0/0x2b0
[ 224.662802] device_is_dependent+0x108/0x2b0
[ 224.662808] device_link_add+0x1f8/0x10b0
[ 224.662813] devm_of_phy_get_by_index+0x120/0x200
[ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp]
[ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm]
[ 224.662864] component_bind_all+0x3a8/0x720
[ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm]
[ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838
[ 224.662904] component_master_add_with_match+0x1f4/0x230
[ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm]
[ 224.662939] platform_probe+0xe8/0x168
[ 224.662945] really_probe+0x340/0x828
[ 224.662950] __driver_probe_device+0x2e0/0x350
[ 224.662954] driver_probe_device+0x80/0x140
[ 224.662959] __driver_attach+0x398/0x460
[ 224.662964] bus_for_each_dev+0xe0/0x198
[ 224.662968] driver_attach+0x50/0x68
[ 224.662972] bus_add_driver+0x2a0/0x4c0
[ 224.662977] driver_register+0x294/0x360
[ 224.662982] __platform_driver_register+0x7c/0x98
[ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm]
...
Unregister the AUX adapter on bridge detach.
Fixes: 86eecc3a9c2e ("drm/bridge: synopsys: Add DW DPTX Controller support library")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index e7bef9150f6a..8d02f047693a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -1751,6 +1751,13 @@ static const struct drm_edid *dw_dp_bridge_edid_read(struct drm_bridge *bridge,
return edid;
}
+static void dw_dp_bridge_detach(struct drm_bridge *bridge)
+{
+ struct dw_dp *dp = bridge_to_dp(bridge);
+
+ drm_dp_aux_unregister(&dp->aux);
+}
+
static u32 *dw_dp_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
struct drm_bridge_state *bridge_state,
struct drm_crtc_state *crtc_state,
@@ -1824,6 +1831,7 @@ static const struct drm_bridge_funcs dw_dp_bridge_funcs = {
.atomic_disable = dw_dp_bridge_atomic_disable,
.detect = dw_dp_bridge_detect,
.edid_read = dw_dp_bridge_edid_read,
+ .detach = dw_dp_bridge_detach,
};
static int dw_dp_link_retrain(struct dw_dp *dp)
--
2.52.0Am Montag, 9. März 2026, 23:44:35 Mitteleuropäische Normalzeit schrieb Cristian Ciocaltea: > The DisplayPort AUX channel gets initialized and registered during > dw_dp_bind(), but it is never unregistered, which may lead to resource > leaks and/or use-after-free: > > [ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0 > [ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658 > ... > [ 224.662796] device_is_dependent+0xe0/0x2b0 > [ 224.662802] device_is_dependent+0x108/0x2b0 > [ 224.662808] device_link_add+0x1f8/0x10b0 > [ 224.662813] devm_of_phy_get_by_index+0x120/0x200 > [ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp] > [ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm] > [ 224.662864] component_bind_all+0x3a8/0x720 > [ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm] > [ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838 > [ 224.662904] component_master_add_with_match+0x1f4/0x230 > [ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm] > [ 224.662939] platform_probe+0xe8/0x168 > [ 224.662945] really_probe+0x340/0x828 > [ 224.662950] __driver_probe_device+0x2e0/0x350 > [ 224.662954] driver_probe_device+0x80/0x140 > [ 224.662959] __driver_attach+0x398/0x460 > [ 224.662964] bus_for_each_dev+0xe0/0x198 > [ 224.662968] driver_attach+0x50/0x68 > [ 224.662972] bus_add_driver+0x2a0/0x4c0 > [ 224.662977] driver_register+0x294/0x360 > [ 224.662982] __platform_driver_register+0x7c/0x98 > [ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm] > ... > > Unregister the AUX adapter on bridge detach. that sounds sort of asymmetrical though. drm_bridge_funcs has attach and detach callbacks and the component-framework also has bind and unbind callbacks. This might cause confusion later on I guess, especially as I don't know if there could be a bridge attach, after the detach that unregisters the aux adapter. Looking at the AnalogixDP for example, it does the the register and unregister in the bind/unbind callbacks of the core driver. So I guess the in my eyes cleaner way would be to introduce a dw_dp_unbind() function and put the aux unregister there? At least that way, everything would be at the same "level". Heiko
Hello Heiko, On 3/26/26 9:28 PM, Heiko Stuebner wrote: > Am Montag, 9. März 2026, 23:44:35 Mitteleuropäische Normalzeit schrieb Cristian Ciocaltea: >> The DisplayPort AUX channel gets initialized and registered during >> dw_dp_bind(), but it is never unregistered, which may lead to resource >> leaks and/or use-after-free: >> >> [ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0 >> [ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658 >> ... >> [ 224.662796] device_is_dependent+0xe0/0x2b0 >> [ 224.662802] device_is_dependent+0x108/0x2b0 >> [ 224.662808] device_link_add+0x1f8/0x10b0 >> [ 224.662813] devm_of_phy_get_by_index+0x120/0x200 >> [ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp] >> [ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm] >> [ 224.662864] component_bind_all+0x3a8/0x720 >> [ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm] >> [ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838 >> [ 224.662904] component_master_add_with_match+0x1f4/0x230 >> [ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm] >> [ 224.662939] platform_probe+0xe8/0x168 >> [ 224.662945] really_probe+0x340/0x828 >> [ 224.662950] __driver_probe_device+0x2e0/0x350 >> [ 224.662954] driver_probe_device+0x80/0x140 >> [ 224.662959] __driver_attach+0x398/0x460 >> [ 224.662964] bus_for_each_dev+0xe0/0x198 >> [ 224.662968] driver_attach+0x50/0x68 >> [ 224.662972] bus_add_driver+0x2a0/0x4c0 >> [ 224.662977] driver_register+0x294/0x360 >> [ 224.662982] __platform_driver_register+0x7c/0x98 >> [ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm] >> ... >> >> Unregister the AUX adapter on bridge detach. > > that sounds sort of asymmetrical though. drm_bridge_funcs has attach and > detach callbacks and the component-framework also has bind and unbind > callbacks. > > This might cause confusion later on I guess, especially as I don't know > if there could be a bridge attach, after the detach that unregisters the > aux adapter. > > Looking at the AnalogixDP for example, it does the the register and > unregister in the bind/unbind callbacks of the core driver. > > So I guess the in my eyes cleaner way would be to introduce a > dw_dp_unbind() function and put the aux unregister there? > > At least that way, everything would be at the same "level". You are right. As a matter of fact exporting the *_unbind() in the library was my first thought, but for some reason I went with the "auto" approach. I've just handled this in v3 [1]. Thanks for reviewing and picking the rest of the patches! Regards, Cristian [1] https://lore.kernel.org/all/20260327-drm-rk-fixes-v3-0-fd2e6900c08c@collabora.com/
© 2016 - 2026 Red Hat, Inc.