diff options
author | Takashi Iwai <tiwai@suse.de> | 2019-01-25 17:11:32 +0100 |
---|---|---|
committer | Takashi Iwai <tiwai@suse.de> | 2019-01-25 19:45:46 +0100 |
commit | e190161f96b88ffae870405fd6c3fdd1d2e7f98d (patch) | |
tree | 6b1451f9729cec88857440eec1aac51c6b04307c /include/sound | |
parent | 9e6966646b6bc5078d579151b90016522d4ff2cb (diff) | |
download | linux-e190161f96b88ffae870405fd6c3fdd1d2e7f98d.tar.bz2 |
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>
Diffstat (limited to 'include/sound')
0 files changed, 0 insertions, 0 deletions