linux-kernel - [PATCH 4.20 59/80] ALSA: pcm: Fix tight loop of OSS capture stream

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon,  4 Feb 2019 11:37:19 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org,
        syzbot+fbe0496f92a0ce7b786c@...kaller.appspotmail.com,
        Takashi Iwai <tiwai@...e.de>
Subject: [PATCH 4.20 59/80] ALSA: pcm: Fix tight loop of OSS capture stream

4.20-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <tiwai@...e.de>

commit e190161f96b88ffae870405fd6c3fdd1d2e7f98d upstream.

When the trigger=off is passed for a PCM OSS stream, it sets the
start_threshold of the given substream to the boundary size, so that
it won't be automatically started.  This can be problematic for a
capture stream, unfortunately, as detected by syzkaller.  The scenario
is like the following:

- 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.
- The function at this check returns 0 with trigger=off since we
  explicitly disable the auto-start.
- The loop continues and repeats calling __snd_pcm_lib_xfer() 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, __snd_pcm_lib_xfer() could wait even for the native API
 usage cases, too; but I'd like to stay in a safer side for not
 breaking the existing stuff for now.)

Reported-by: syzbot+fbe0496f92a0ce7b786c@...kaller.appspotmail.com
Cc: <stable@...r.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@...e.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

---
 sound/core/pcm_lib.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -2112,6 +2112,13 @@ int pcm_lib_apply_appl_ptr(struct snd_pc
 	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(str
 			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;