summaryrefslogtreecommitdiff
path: root/sound/hda/hdmi_chmap.c
diff options
context:
space:
mode:
authorTakashi Iwai <tiwai@suse.de>2018-03-22 18:10:14 +0100
committerTakashi Iwai <tiwai@suse.de>2018-03-23 22:17:56 +0100
commit02a5d6925cd34c3b774bdb8eefb057c40a30e870 (patch)
treef1eccf173a81c9efedc38585ffcb82d6ba4aeb13 /sound/hda/hdmi_chmap.c
parentf3b906d720e429a3acd95f8cbd4fda366fb1659d (diff)
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>
Diffstat (limited to 'sound/hda/hdmi_chmap.c')
0 files changed, 0 insertions, 0 deletions