Skip to contentSkip to conversation

ASoC: SOF: Correct sps->stream and cstream nullity management

PATCH Superseded Peter Ujfalusi 2 participants 5 messages Nov 7, 2024 – Feb 6, 2025

Subsystems (4)
lore
Share & tools
lore

Peter Ujfalusi

author maintainer
#0 lore raw

v2 cover ASoC: SOF: Correct sps->stream and cstream nullity management

Hi,

Changes since v1:
- Cc stable

The nullity of sps->cstream needs to be checked in sof_ipc_msg_data() and not assume that it is not NULL.
The sps->stream must be cleared to NULL on close since this is used as a check to see if we have active PCM stream.

Regards,
Peter
---
Peter Ujfalusi (2):
ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()
ASoC: SOF: pcm: Clear the susbstream pointer to NULL on close

 sound/soc/sof/pcm.c        | 2 ++
 sound/soc/sof/stream-ipc.c | 6 +++++-
 2 files changed, 7 insertions(+), 1 deletion(-)
Signature · 1 line
2.47.0
author maintainer
#1 lore raw

PATCH v2 1/2 ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()

The nullity of sps->cstream should be checked similarly as it is done in sof_set_stream_data_offset() function.
Assuming that it is not NULL if sps->stream is NULL is incorrect and can lead to NULL pointer dereference.

---
 sound/soc/sof/stream-ipc.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
sound/soc/sof/stream-ipc.c +5 -1
index 794c7bbccbaf..8262443ac89a 100644
@@ -43,7 +43,7 @@ int sof_ipc_msg_data(struct snd_sof_dev *sdev,
 				return -ESTRPIPE;
 
 			posn_offset = stream->posn_offset;
-		} else {
+		} else if (sps->cstream) {
 
 			struct sof_compr_stream *sstream = sps->cstream->runtime->private_data;
 
@@ -51,6 +51,10 @@ int sof_ipc_msg_data(struct snd_sof_dev *sdev,
 				return -ESTRPIPE;
 
 			posn_offset = sstream->posn_offset;
+
+		} else {
+			dev_err(sdev->dev, "%s: No stream opened\n", __func__);
+			return -EINVAL;
 		}
 
 		snd_sof_dsp_mailbox_read(sdev, posn_offset, p, sz);
Signature · 1 line
2.47.0
maintainer
#2 lore raw

Re: [PATCH v2 1/2] ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()

Quoted 6 lines · Peter Ujfalusi

The nullity of sps->cstream should be checked similarly as it is done in sof_set_stream_data_offset() function.
Assuming that it is not NULL if sps->stream is NULL is incorrect and can lead to NULL pointer dereference.

Fixes ef8ba9f79953 ("ASoC: SOF: Add support for compress API for stream data/offset")

This commit, also referenced in the second patch, doesn't exist.

author maintainer
#3 lore raw

PATCH v2 2/2 ASoC: SOF: pcm: Clear the susbstream pointer to NULL on close

In reply to Peter Ujfalusi

The spcm->stream[substream->stream].substream is set during open and was left untouched. After the first PCM stream it will never be NULL and we have code which checks for substream NULLity as indication if the stream is active or not.
For the compressed cstream pointer the same has been done, this change will correct the handling of PCM streams.

---
 sound/soc/sof/pcm.c | 2 ++
 1 file changed, 2 insertions(+)
sound/soc/sof/pcm.c +2 -0
index 35a7462d8b69..c5c6353f18ce 100644
@@ -511,6 +511,8 @@ static int sof_pcm_close(struct snd_soc_component *component,
 		 */
 	}
 
+	spcm->stream[substream->stream].substream = NULL;
+
 	return 0;
 }
 
Signature · 1 line
2.47.0
maintainer
#4 lore raw
In reply to Peter Ujfalusi
Quoted 9 lines · Peter Ujfalusi

Changes since v1:
- Cc stable

The nullity of sps->cstream needs to be checked in sof_ipc_msg_data() and not assume that it is not NULL.
The sps->stream must be cleared to NULL on close since this is used as a check to see if we have active PCM stream.

[...]

Applied to

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

Thanks!

[1/2] ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()

      commit: d8d99c3b5c485f339864aeaa29f76269cc0ea975
[2/2] ASoC: SOF: pcm: Clear the susbstream pointer to NULL on close
      commit: 46c7b901e2a03536df5a3cb40b3b26e2be505df6

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