drm/bridge: dw-hdmi-qp: Guard clear_audio_infoframe when PHY is down
Subsystems (5)
PATCH 1/1 drm/bridge: dw-hdmi-qp: Guard clear_audio_infoframe when PHY is down
The following panic was observed during system reboot:
Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 6 UID: 1000 PID: 2348 Comm: pipewire ... 7.0.5+ #4 PREEMPT(full) Call trace: ... regmap_update_bits_base+0x70/0xa8 dw_hdmi_qp_bridge_clear_audio_infoframe+0x3c/0x58 [dw_hdmi_qp] drm_bridge_connector_clear_audio_infoframe+0x2c/0x48 [drm_display_helper] ... dw_hdmi_qp_audio_disable+0x28/0xa8 [dw_hdmi_qp] drm_bridge_connector_audio_shutdown+0x38/0x68 [drm_display_helper] drm_connector_hdmi_audio_shutdown+0x28/0x40 [drm_display_helper] hdmi_codec_shutdown+0x60/0x90 [snd_soc_hdmi_codec] ... snd_pcm_release_substream+0xcc/0x120 [snd_pcm] snd_pcm_release+0x4c/0xc0 [snd_pcm] ...
The root cause is pipewire tries to close the HDMI audio device after atomic_disable(), which sets tmds_char_rate to 0 and disables the PHY.
In this case, dw_hdmi_qp_audio_disable() will call dw_hdmi_qp_bridge_clear_audio_infoframe(), accessing register without checking tmds_char_rate.
Guard the register access in drm_display_helper callback function with tmds_char_rate check.
---
Changes in v2:
- Move drm_atomic_helper_connector_hdmi_clear_audio_infoframe() inside the if (hdmi->tmds_char_rate) of dw_hdmi_qp_audio_disable().
- Link to v1: https://lore.kernel.org/all/[email protected]/
Changes in v3:
- Add a tmds_char_rate guard in clear_audio_infoframe path.
- Decouple write_audio_infoframe from clear_audio_infoframe.
- Balance the PKTSCHED_AMD_TX_EN bit enable/disable.
- Link to v2: https://lore.kernel.org/all/[email protected]/
Changes in v4:
- Update panic stack on 7.0.5
- Link to v3: https://lore.kernel.org/all/[email protected]/
Changes in v5:
- Reuse the origin dw_hdmi_qp_bridge_clear_audio_infoframe and add tmds_char_rate guard in new callback function.
- Link to v4: https://lore.kernel.org/all/[email protected]/
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +12 -2
@@ -880,7 +880,7 @@ static int dw_hdmi_qp_bridge_clear_spd_infoframe(struct drm_bridge *bridge)return 0 ; } -static int dw_hdmi_qp_bridge_clear_audio_infoframe (struct drm_bridge *bridge) +static int __dw_hdmi_qp_bridge_clear_audio_infoframe (struct drm_bridge *bridge) {struct dw_hdmi_qp *hdmi = bridge->driver_private;
@@ -893,6 +893,16 @@ static int dw_hdmi_qp_bridge_clear_audio_infoframe(struct drm_bridge *bridge)return 0 ; } +static int dw_hdmi_qp_bridge_clear_audio_infoframe (struct drm_bridge *bridge) +{ +struct dw_hdmi_qp *hdmi = bridge->driver_private; + +if (hdmi->tmds_char_rate >0 ) +return __dw_hdmi_qp_bridge_clear_audio_infoframe (bridge); + +return 0 ; +} +static void dw_hdmi_qp_write_pkt (struct dw_hdmi_qp *hdmi,const u8 *buffer,size_t start,size_t len,unsigned int reg) {
@@ -987,7 +997,7 @@ static int dw_hdmi_qp_bridge_write_audio_infoframe(struct drm_bridge *bridge, {struct dw_hdmi_qp *hdmi = bridge->driver_private; -dw_hdmi_qp_bridge_clear_audio_infoframe (bridge); +__dw_hdmi_qp_bridge_clear_audio_infoframe (bridge);/* * AUDI_CONTENTS0: { RSV, HB2, HB1, RSV }
Signature · 1 line
2.55.0
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing synchronization lock between DRM atomic disable and ALSA callbacks leaves a Time-Of-Check to Time-Of-Use (TOCTOU) race condition, failing to fix the kernel panic. --
commit 41e47d6bcdba49646deba6ac74845c934529f2f4
Author: Frank Zhang <[email protected]>
drm/bridge: dw-hdmi-qp: Guard clear_audio_infoframe when PHY is down
This commit attempts to fix a kernel panic caused when an audio server closes the HDMI audio device concurrently with an atomic_disable. It tries to guard register accesses in the audio teardown path by checking the tmds_char_rate state variable.
Quoted 4 lines
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +0
-0
[ ... ]
Quoted 4 lines
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +0
-0@@ -893,6 +893,16 @@ static int dw_hdmi_qp_bridge_clear_audio_infoframe(struct drm_bridge *bridge)return 0 ; }
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c static int dw_hdmi_qp_bridge_clear_audio_infoframe(struct drm_bridge *bridge) · line 905
Quoted 10 lines
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +10
-0+static int dw_hdmi_qp_bridge_clear_audio_infoframe (struct drm_bridge *bridge) +{ +struct dw_hdmi_qp *hdmi = bridge->driver_private; + +if (hdmi->tmds_char_rate >0 ) +return __dw_hdmi_qp_bridge_clear_audio_infoframe (bridge); + +return 0 ; +} +
[Severity: High]
This isn't a bug introduced by this patch, but does this lockless check leave an open Time-Of-Check to Time-Of-Use (TOCTOU) race condition?
If a userspace audio server (like pipewire) closes the HDMI audio device at the same time as a DRM modeset disables the display, the ALSA teardown path can execute dw_hdmi_qp_bridge_clear_audio_infoframe() and successfully evaluate this unguarded check.
Concurrently, dw_hdmi_qp_bridge_atomic_disable() can execute:
hdmi->tmds_char_rate = 0;
hdmi->phy.ops->disable(hdmi, hdmi->phy.data);This zeroes the state variable and powers off the PHY without synchronization. The ALSA thread can then resume and invoke __dw_hdmi_qp_bridge_clear_audio_infoframe(), writing to the now-disabled PHY registers and triggering the Asynchronous SError Interrupt panic this patch is trying to fix.
Additionally, could the same race exist in dw_hdmi_qp_audio_prepare()?
if (!hdmi->tmds_char_rate)
return -ENODEV;
// ... further down ...
dw_hdmi_qp_set_audio_interface(hdmi, fmt, hparms);This path configures multiple registers after a lockless check, making the entire preparation sequence vulnerable to the same race condition.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1