Re: [PATCH v4 1/2] ASoC: codecs: nau8360: Block DSP path selection when firmware load fails
From: sashiko-bot@kernel.org
Date: 2026-09-09 03:13:54
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Time-of-check to time-of-use (TOCTOU) race when checking DAPM bias level, allowing path changes during active playback.
--
commit b29bd8969729968f9e98cb8e88c840d31f1aa474
Author: Neo Chang [off-list ref]
ASoC: codecs: nau8360: Block DSP path selection when firmware load fails
This commit blocks DSP path selection if the firmware fails to load,
preventing invalid routing states. It ensures invalid userspace requests
are rejected with -EBUSY to maintain the original hardware state.
quoted hunk ↗ jump to hunk
diff --git a/sound/soc/codecs/nau8360.c b/sound/soc/codecs/nau8360.c --- a/sound/soc/codecs/nau8360.c +++ b/sound/soc/codecs/nau8360.c@@ -715,10 +715,15 @@ static int nau8360_dac_mux_put_enum(struct snd_kcontrol *kcontrol, int ret = 0; if (snd_soc_dapm_get_bias_level(dapm) > SND_SOC_BIAS_STANDBY) { - dev_warn(nau8360->dev, "changing path is not allowed during playback"); + dev_warn_ratelimited(nau8360->dev, "changing path is not allowed during playback"); return ret; } + if (item[0] == NAU8360_DAC_SRC_DSP && !nau8360->load_fw_done) { + dev_warn_ratelimited(nau8360->dev, "Cannot enable DSP: Firmware not ready or disabled\n"); + return -EBUSY; + } + mutex_lock(&nau8360->lock); ret = snd_soc_dapm_put_enum_double(kcontrol, ucontrol);
[Severity: High]
This is a pre-existing issue, but does nau8360_dac_mux_put_enum() have a
time-of-check to time-of-use (TOCTOU) race when checking the DAPM bias level?
The follow-up fix in this series ("ASoC: codecs: nau8360: Fix AB-BA deadlock
in mux update") adds dapm_mutex locking to this function but fails to resolve
the race condition.
If a concurrent userspace mixer update and a PCM stream start occur, the mixer
update thread can check that the bias level is <= SND_SOC_BIAS_STANDBY.
Once the lock is dropped (or before it is held, in the current patch state),
the PCM stream can start, acquire the dapm_mutex, transition the bias level to
SND_SOC_BIAS_ON, and release the lock.
Then, snd_soc_dapm_put_enum_double() re-acquires the lock internally and
blindly applies the path change while playback is active.
Can this sequence cause the hardware routing path to be mutated while audio
is active, potentially leading to invalid hardware routing states or audio
glitches?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260909025947.287120-1-YLCHANG2@nuvoton.com?part=1