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)
committerSasha Levin <sasha.levin@oracle.com>
Mon, 15 Feb 2016 20:45:32 +0000 (15:45 -0500)
commita2c892c31423bdef823c6f6b2d54c159be8f4e20
treee4a22eca025a6d315832b551972d5ec2479168e7
parent8bd8e5389ea62cdefa03d383daccb6474fef93a6
ALSA: rawmidi: Fix race at copying & updating the position

[ Upstream commit 81f577542af15640cbcb6ef68baa4caa610cbbfc ]

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>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
sound/core/rawmidi.c