[PATCH] ASoC: fsl_asrc: check the second front-end DMA channel

The temporary Front-End DMA request can fail independently of the
persistent channel acquired earlier in fsl_asrc_dma_hw_params(). The
returned NULL pointer is immediately used to read its private data.

Check the temporary channel and release the previously acquired
persistent Front-End channel on failure. Clear its slot so a later
hw_free cannot release it twice. ASoC marks a component's hw_params
only after success and skips unmarked components during rollback, so
returning an error alone would leak the earlier channel.

Detected by static analysis and reviewed with AI-assisted source auditing.

Fixes: 3117bb3109dc ("ASoC: fsl_asrc: Add ASRC ASoC CPU DAI and platform drivers")
Assisted-by: LLM
Signed-off-by: Slavin Liu <redacted>
---
 sound/soc/fsl/fsl_asrc_dma.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index 2f662bdf14d0..64f2b0612274 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c

@@ -248,6 +248,11 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
 
 		/* Get DMA request of Front-End */
 		tmp_chan = asrc->get_dma_channel(pair, dir);
+		if (!tmp_chan) {
+			dma_release_channel(pair->dma_chan[!dir]);
+			pair->dma_chan[!dir] = NULL;
+			return -EINVAL;
+		}
 		tmp_data = tmp_chan->private;
 		pair->dma_data.dma_request2 = tmp_data->dma_request;
 		pair->dma_data.peripheral_type = tmp_data->peripheral_type;

On Sun, 13 Sep 2026 20:51:47 +0800, Slavin Liu wrote:

ASoC: fsl_asrc: check the second front-end DMA channel

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.4

Thanks!

[1/1] ASoC: fsl_asrc: check the second front-end DMA channel
      https://git.kernel.org/broonie/sound/c/b4136c0d69ea

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

On Sun, Sep 13, 2026 at 08:51:47PM +0800, Slavin Liu wrote:

The ->get_dma_channel() function pointer returns error pointers not
NULL.

    sound/soc/fsl/fsl_asrc_dma.c:254 fsl_asrc_dma_hw_params()
    warn: 'tmp_chan' is an error pointer or valid

sound/soc/fsl/fsl_easrc.c | (struct fsl_asrc)->get_dma_channel | fsl_easrc_get_dma_channel | 1
sound/soc/fsl/fsl_asrc.c | (struct fsl_asrc)->get_dma_channel | fsl_asrc_get_dma_channel | 1

regards,
dan carpenter

Hi Dan,

On Sat, Sep 26, 2026 at 04:19:38PM +0300, Dan Carpenter wrote:

The ->get_dma_channel() function pointer returns error pointers not
NULL.

    sound/soc/fsl/fsl_asrc_dma.c:254 fsl_asrc_dma_hw_params()
    warn: 'tmp_chan' is an error pointer or valid

sound/soc/fsl/fsl_easrc.c | (struct fsl_asrc)->get_dma_channel | fsl_easrc_get_dma_channel | 1
sound/soc/fsl/fsl_asrc.c | (struct fsl_asrc)->get_dma_channel | fsl_asrc_get_dma_channel | 1

Is this a false positive?: both implementations return
dma_request_slave_channel(), which is an inline wrapper converting the
ERR_PTR from dma_request_chan() to NULL before returning:

	static inline struct dma_chan * __deprecated
	dma_request_slave_channel(struct device *dev, const char *name)
	{
		struct dma_chan *ch = dma_request_chan(dev, name);

		return IS_ERR(ch) ? NULL : ch;
	}

So ->get_dma_channel() return NULL or a valid pointer.

The same function backs this up: the persistent Front-End channel a
few lines above comes from the same function pointer and is checked
with !pair->dma_chan[!dir], while the Back-End channel is requested
with dma_request_chan() directly and uses IS_ERR() -- the two check
styles in one function match the two APIs.

Best regards,
Slavin Liu

On Sat, Sep 26, 2026 at 10:10:11PM +0800, Slavin Liu wrote:

Hi Dan,

On Sat, Sep 26, 2026 at 04:19:38PM +0300, Dan Carpenter wrote:

quoted

The ->get_dma_channel() function pointer returns error pointers not
NULL.

    sound/soc/fsl/fsl_asrc_dma.c:254 fsl_asrc_dma_hw_params()
    warn: 'tmp_chan' is an error pointer or valid

sound/soc/fsl/fsl_easrc.c | (struct fsl_asrc)->get_dma_channel | fsl_easrc_get_dma_channel | 1
sound/soc/fsl/fsl_asrc.c | (struct fsl_asrc)->get_dma_channel | fsl_asrc_get_dma_channel | 1

Is this a false positive?: both implementations return
dma_request_slave_channel().

Ah, you're looking at old code.  It changed from NULL to error pointers
last week.  The dma_request_slave_channel() function was deleted entirely
since there are no more callers in the kernel.

https://lore.kernel.org/all/20260918113727.1898998-6-andriy.shevchenko@linux.intel.com/

regards,
dan carpenter

Hi Dan,

You're right, sorry for the noise.  My v1 was written against mainline,
where dma_request_slave_channel() still exists, but Mark applied Andy's
conversion (b045248399d0) to for-7.4 three days before applying my
patch (b4136c0d69ea), so there ->get_dma_channel() propagates error
pointers and the !NULL check is ineffective.

I've just sent an incremental patch converting the check to IS_ERR()
("ASoC: fsl_asrc: fix second front-end channel check").

Best regards,
Slavin Liu