ALSA: rawmidi: Fix race at copying & updating the position
authorTakashi Iwai <tiwai@suse.de>
Wed, 3 Feb 2016 13:41:22 +0000 (14:41 +0100)
committerBen Hutchings <ben@decadent.org.uk>
Sat, 27 Feb 2016 14:28:46 +0000 (14:28 +0000)
commita0e3501f63314e7c6212820ae1e5c3f1f8eae733
tree88aaf03a87bc0132d2527106930a7128aa02ba5f
parentb6d584749c4b03695688f47390a0939594d9b06c
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: Ben Hutchings <ben@decadent.org.uk>
sound/core/rawmidi.c