ALSA: pcm: Fix tight loop of OSS capture stream
authorTakashi Iwai <tiwai@suse.de>
Fri, 25 Jan 2019 16:11:32 +0000 (17:11 +0100)
committerTakashi Iwai <tiwai@suse.de>
Fri, 25 Jan 2019 18:45:46 +0000 (19:45 +0100)
commite190161f96b88ffae870405fd6c3fdd1d2e7f98d
tree6b1451f9729cec88857440eec1aac51c6b04307c
parent9e6966646b6bc5078d579151b90016522d4ff2cb
ALSA: pcm: Fix tight loop of OSS capture stream

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@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
sound/core/pcm_lib.c