diff options
author | Takashi Iwai <tiwai@suse.de> | 2016-02-03 14:41:22 +0100 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2016-02-17 12:30:58 -0800 |
commit | 49ba9e222aa5a079cf89d2a86da9838aa0213a60 (patch) | |
tree | c247bac12e763355c14aa8e7dbe0cafb010c47cc /sound/pci/hda | |
parent | 8af97f7c418ddc9c3e7a649414c70e798b134e50 (diff) | |
download | linux-stable-49ba9e222aa5a079cf89d2a86da9838aa0213a60.tar.gz linux-stable-49ba9e222aa5a079cf89d2a86da9838aa0213a60.tar.bz2 linux-stable-49ba9e222aa5a079cf89d2a86da9838aa0213a60.zip |
ALSA: rawmidi: Fix race at copying & updating the position
commit 81f577542af15640cbcb6ef68baa4caa610cbbfc upstream.
The rawmidi read and write functions manage runtime stream status
such as runtime->appl_ptr and runtime->avail. These point where to
copy the new data and how many bytes have been copied (or to be
read). The problem is that rawmidi read/write call copy_from_user()
or copy_to_user(), and the runtime spinlock is temporarily unlocked
and relocked while copying user-space. Since the current code
advances and updates the runtime status after the spin unlock/relock,
the copy and the update may be asynchronous, and eventually
runtime->avail might go to a negative value when many concurrent
accesses are done. This may lead to memory corruption in the end.
For fixing this race, in this patch, the status update code is
performed in the same lock before the temporary unlock. Also, the
spinlock is now taken more widely in snd_rawmidi_kernel_read1() for
protecting more properly during the whole operation.
BugLink: http://lkml.kernel.org/r/CACT4Y+b-dCmNf1GpgPKfDO0ih+uZCL2JV4__j-r1kdhPLSgQCQ@mail.gmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'sound/pci/hda')
0 files changed, 0 insertions, 0 deletions