ALSA: pcm: Avoid potential races between OSS ioctls and read/write
authorTakashi Iwai <tiwai@suse.de>
Thu, 22 Mar 2018 17:10:14 +0000 (18:10 +0100)
committerTakashi Iwai <tiwai@suse.de>
Fri, 23 Mar 2018 21:17:56 +0000 (22:17 +0100)
commit02a5d6925cd34c3b774bdb8eefb057c40a30e870
treef1eccf173a81c9efedc38585ffcb82d6ba4aeb13
parentf3b906d720e429a3acd95f8cbd4fda366fb1659d
ALSA: pcm: Avoid potential races between OSS ioctls and read/write

Although we apply the params_lock mutex to the whole read and write
operations as well as snd_pcm_oss_change_params(), we may still face
some races.

First off, the params_lock is taken inside the read and write loop.
This is intentional for avoiding the too long locking, but it allows
the in-between parameter change, which might lead to invalid
pointers.  We check the readiness of the stream and set up via
snd_pcm_oss_make_ready() at the beginning of read and write, but it's
called only once, by assuming that it remains ready in the rest.

Second, many ioctls that may change the actual parameters
(i.e. setting runtime->oss.params=1) aren't protected, hence they can
be processed in a half-baked state.

This patch is an attempt to plug these holes.  The stream readiness
check is moved inside the read/write inner loop, so that the stream is
always set up in a proper state before further processing.  Also, each
ioctl that may change the parameter is wrapped with the params_lock
for avoiding the races.

The issues were triggered by syzkaller in a few different scenarios,
particularly the one below appearing as GPF in loopback_pos_update.

Reported-by: syzbot+c4227aec125487ec3efa@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
sound/core/oss/pcm_oss.c