summaryrefslogtreecommitdiff
path: root/sound/pci/cs46xx
diff options
context:
space:
mode:
authorTakashi Iwai <tiwai@suse.de>2019-01-25 17:11:32 +0100
committerTakashi Iwai <tiwai@suse.de>2019-01-25 19:45:46 +0100
commite190161f96b88ffae870405fd6c3fdd1d2e7f98d (patch)
tree6b1451f9729cec88857440eec1aac51c6b04307c /sound/pci/cs46xx
parent9e6966646b6bc5078d579151b90016522d4ff2cb (diff)
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 'sound/pci/cs46xx')
0 files changed, 0 insertions, 0 deletions