[PATCH v2] ASoC: soc-compress: prevent the potentially use of null pointer
There is one call trace that snd_soc_register_card() ->snd_soc_bind_card()->soc_init_pcm_runtime() ->snd_soc_dai_compress_new()->snd_soc_new_compress(). In the trace the 'codec_dai' transfers from card->dai_link, and we can see from the snd_soc_add_pcm_runtime() in snd_soc_bind_card() that, if value of card->dai_link->num_codecs is 0, then 'codec_dai' could be null pointer caused by index out of bound in 'asoc_rtd_to_codec(rtd, 0)'. And snd_soc_register_card() is called by various platforms. Therefore, it is better to add the check in the case of misusing. And because 'cpu_dai' has already checked in soc_init_pcm_runtime(), there is no need to check again. Adding the check as follow, then if 'codec_dai' is null, snd_soc_new_compress() will not pass through the check 'if (playback + capture != 1)', avoiding the leftover use of 'codec_dai'.
Fixes: 467fece ("ASoC: soc-dai: move snd_soc_dai_stream_valid() to soc-dai.c") Signed-off-by: Jiasheng Jiang jiasheng@iscas.ac.cn Reported-by: kernel test robot lkp@intel.com Reported-by: Dan Carpenter dan.carpenter@oracle.com --- sound/soc/soc-compress.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index b4f5935..67c3df1 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -535,12 +535,14 @@ int snd_soc_new_compress(struct snd_soc_pcm_runtime *rtd, int num) }
/* check client and interface hw capabilities */ - if (snd_soc_dai_stream_valid(codec_dai, SNDRV_PCM_STREAM_PLAYBACK) && - snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_PLAYBACK)) - playback = 1; - if (snd_soc_dai_stream_valid(codec_dai, SNDRV_PCM_STREAM_CAPTURE) && - snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_CAPTURE)) - capture = 1; + if (codec_dai) { + if (snd_soc_dai_stream_valid(codec_dai, SNDRV_PCM_STREAM_PLAYBACK) && + snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_PLAYBACK)) + playback = 1; + if (snd_soc_dai_stream_valid(codec_dai, SNDRV_PCM_STREAM_CAPTURE) && + snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_CAPTURE)) + capture = 1; + }
/* * Compress devices are unidirectional so only one of the directions
On Fri, 15 Oct 2021 08:13:53 +0000, Jiasheng Jiang wrote:
There is one call trace that snd_soc_register_card() ->snd_soc_bind_card()->soc_init_pcm_runtime() ->snd_soc_dai_compress_new()->snd_soc_new_compress(). In the trace the 'codec_dai' transfers from card->dai_link, and we can see from the snd_soc_add_pcm_runtime() in snd_soc_bind_card() that, if value of card->dai_link->num_codecs is 0, then 'codec_dai' could be null pointer caused by index out of bound in 'asoc_rtd_to_codec(rtd, 0)'. And snd_soc_register_card() is called by various platforms. Therefore, it is better to add the check in the case of misusing. And because 'cpu_dai' has already checked in soc_init_pcm_runtime(), there is no need to check again. Adding the check as follow, then if 'codec_dai' is null, snd_soc_new_compress() will not pass through the check 'if (playback + capture != 1)', avoiding the leftover use of 'codec_dai'.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: soc-compress: prevent the potentially use of null pointer commit: de2c6f98817fa5decb9b7d3b3a8a3ab864c10588
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
participants (2)
-
Jiasheng Jiang
-
Mark Brown