When the trigger=off is passed for a PCM OSS stream, it sets the
start_threshold of the substream to the boundary. This can be
problematic for a capture stream, unfortunately, like the following,
as detected by syzkaller:
- In __snd_pcm_lib_xfer() that is invoked from snd_pcm_oss_read()
loop, we have a check whether the stream was already started or the
stream can be auto-started.
- With trigger=0, we explicitly disable the auto-start, and the
function returns 0 at this check.
- The loop continues tightly, which may lead to an RCU stall.
This patch fixes the bug by simply allowing the wait for non-started
stream in the case of OSS capture. For native usages, it's supposed
to be done by the caller side (which is user-space), hence it returns
zero like before.
(In theory, this could wait there, but I'd like to stay in a safer
side for not breaking the existing stuff.)
Reported-by: syzbot+fbe0496f92a0ce7b786c@xxxxxxxxxxxxxxxxxxxxxxxxx
Cc: <stable@xxxxxxxxxxxxxxx>
Signed-off-by: Takashi Iwai <tiwai@xxxxxxx>
---
sound/core/pcm_lib.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 40013b26f671..6c99fa8ac5fa 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -2112,6 +2112,13 @@ int pcm_lib_apply_appl_ptr(struct snd_pcm_substream *substream,
return 0;
}
+/* allow waiting for a capture stream that hasn't been started */
+#if IS_ENABLED(CONFIG_SND_PCM_OSS)
+#define wait_capture_start(substream) ((substream)->oss.oss)
+#else
+#define wait_capture_start(substream) false
+#endif
+
/* the common loop for read/write data */
snd_pcm_sframes_t __snd_pcm_lib_xfer(struct snd_pcm_substream *substream,
void *data, bool interleaved,
@@ -2182,7 +2189,7 @@ snd_pcm_sframes_t __snd_pcm_lib_xfer(struct snd_pcm_substream *substream,
err = snd_pcm_start(substream);
if (err < 0)
goto _end_unlock;
- } else {
+ } else if (!wait_capture_start(substream)) {
/* nothing to do */
err = 0;
goto _end_unlock;
--
2.16.4
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
