]> git.baikalelectronics.ru Git - kernel.git/commit
ALSA: pcm: Fix possible OOB access in PCM oss plugins
authorTakashi Iwai <tiwai@suse.de>
Fri, 22 Mar 2019 15:00:54 +0000 (16:00 +0100)
committerTakashi Iwai <tiwai@suse.de>
Fri, 22 Mar 2019 15:27:03 +0000 (16:27 +0100)
commit494bb0c212d54050248c19970408294a52cb9868
tree8fa36cfafe7dbd31bad5c36eb23e019b6e453725
parent5016f84cb8e75de22e58f347485a04b98680b0c2
ALSA: pcm: Fix possible OOB access in PCM oss plugins

The PCM OSS emulation converts and transfers the data on the fly via
"plugins".  The data is converted over the dynamically allocated
buffer for each plugin, and recently syzkaller caught OOB in this
flow.

Although the bisection by syzbot pointed out to the commit
701918af452c ("ALSA: oss: Use kvzalloc() for local buffer
allocations"), this is merely a commit to replace vmalloc() with
kvmalloc(), hence it can't be the cause.  The further debug action
revealed that this happens in the case where a slave PCM doesn't
support only the stereo channels while the OSS stream is set up for a
mono channel.  Below is a brief explanation:

At each OSS parameter change, the driver sets up the PCM hw_params
again in snd_pcm_oss_change_params_lock().  This is also the place
where plugins are created and local buffers are allocated.  The
problem is that the plugins are created before the final hw_params is
determined.  Namely, two snd_pcm_hw_param_near() calls for setting the
period size and periods may influence on the final result of channels,
rates, etc, too, while the current code has already created plugins
beforehand with the premature values.  So, the plugin believes that
channels=1, while the actual I/O is with channels=2, which makes the
driver reading/writing over the allocated buffer size.

The fix is simply to move the plugin allocation code after the final
hw_params call.

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