linux-stable.git/sound, branch v3.18.28

ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream

2016-03-04T15:18:43+00:00

[ Upstream commit 67ec1072b053c15564e6090ab30127895dc77a89 ]

A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice
in the same code path, e.g. one in snd_pcm_action_nonatomic() and
another in snd_pcm_stream_lock().  Usually this is OK, but when a
write lock is issued between these two read locks, the problem
happens: the write lock is blocked due to the first reade lock, and
the second read lock is also blocked by the write lock.  This
eventually deadlocks.

The reason is the way rwsem manages waiters; it's queued like FIFO, so
even if the writer itself doesn't take the lock yet, it blocks all the
waiters (including reads) queued after it.

As a workaround, in this patch, we replace the standard down_write()
with an spinning loop.  This is far from optimal, but it's good
enough, as the spinning time is supposed to be relatively short for
normal PCM operations, and the code paths requiring the write lock
aren't called so often.

Reported-by: Vinod Koul 
Tested-by: Ramesh Babu 
Cc:  # v3.18+
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: pcm: More kerneldoc updates

2016-03-04T15:18:43+00:00

[ Upstream commit 30b771cf8c3120c5c946811ecc5a9b87a34003a2 ]

Add proper kerneldoc comments to the exported functions.

Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: seq: Fix double port list deletion

2016-03-04T15:18:42+00:00

[ Upstream commit 13d5e5d4725c64ec06040d636832e78453f477b7 ]

The commit [7f0973e973cd: ALSA: seq: Fix lockdep warnings due to
double mutex locks] split the management of two linked lists (source
and destination) into two individual calls for avoiding the AB/BA
deadlock.  However, this may leave the possible double deletion of one
of two lists when the counterpart is being deleted concurrently.
It ends up with a list corruption, as revealed by syzkaller fuzzer.

This patch fixes it by checking the list emptiness and skipping the
deletion and the following process.

BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com
Fixes: 7f0973e973cd ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks)
Reported-by: Dmitry Vyukov 
Tested-by: Dmitry Vyukov 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: seq: Fix leak of pool buffer at concurrent writes

2016-03-04T15:18:42+00:00

[ Upstream commit d99a36f4728fcbcc501b78447f625bdcce15b842 ]

When multiple concurrent writes happen on the ALSA sequencer device
right after the open, it may try to allocate vmalloc buffer for each
write and leak some of them.  It's because the presence check and the
assignment of the buffer is done outside the spinlock for the pool.

The fix is to move the check and the assignment into the spinlock.

(The current implementation is suboptimal, as there can be multiple
 unnecessary vmallocs because the allocation is done before the check
 in the spinlock.  But the pool size is already checked beforehand, so
 this isn't a big problem; that is, the only possible path is the
 multiple writes before any pool assignment, and practically seen, the
 current coverage should be "good enough".)

The issue was triggered by syzkaller fuzzer.

BugLink: http://lkml.kernel.org/r/CACT4Y+bSzazpXNvtAr=WXaL8hptqjHwqEyFA+VN2AWEx=aurkg@mail.gmail.com
Reported-by: Dmitry Vyukov 
Tested-by: Dmitry Vyukov 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: seq: Drop superfluous error/debug messages after malloc failures

2016-03-04T15:18:42+00:00

[ Upstream commit 24db8bbaa3fcfaf0c2faccbff5864b58088ac1f6 ]

The kernel memory allocators already report the errors when the
requested allocation fails, thus we don't need to warn it again in
each caller side.

Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: usb-audio: avoid freeing umidi object twice

2016-03-04T15:18:41+00:00

[ Upstream commit 07d86ca93db7e5cdf4743564d98292042ec21af7 ]

The 'umidi' object will be free'd on the error path by snd_usbmidi_free()
when tearing down the rawmidi interface. So we shouldn't try to free it
in snd_usbmidi_create() after having registered the rawmidi interface.

Found by KASAN.

Signed-off-by: Andrey Konovalov 
Acked-by: Clemens Ladisch 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: timer: Fix race at concurrent reads

2016-03-04T15:18:39+00:00

[ Upstream commit 4dff5c7b7093b19c19d3a100f8a3ad87cb7cd9e7 ]

snd_timer_user_read() has a potential race among parallel reads, as
qhead and qused are updated outside the critical section due to
copy_to_user() calls.  Move them into the critical section, and also
sanitize the relevant code a bit.

Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: timer: Handle disconnection more safely

2016-03-04T15:18:39+00:00

[ Upstream commit 230323dac060123c340cf75997971145a42661ee ]

Currently ALSA timer device doesn't take the disconnection into
account very well; it merely unlinks the timer device at disconnection
callback but does nothing else.  Because of this, when an application
accessing the timer device is disconnected, it may release the
resource before actually closed.  In most cases, it results in a
warning message indicating a leftover timer instance like:
   ALSA: timer xxxx is busy?
But basically this is an open race.

This patch tries to address it.  The strategy is like other ALSA
devices: namely,
- Manage card's refcount at each open/close
- Wake up the pending tasks at disconnection
- Check the shutdown flag appropriately at each possible call

Note that this patch has one ugly hack to handle the wakeup of pending
tasks.  It'd be cleaner to introduce a new disconnect op to
snd_timer_instance ops.  But since it would lead to internal ABI
breakage and it eventually increase my own work when backporting to
stable kernels, I took a different path to implement locally in
timer.c.  A cleanup patch will follow at next for 4.5 kernel.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431
Cc:  # v3.15+
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: timer: Fix race between stop and interrupt

2016-03-04T15:18:38+00:00

[ Upstream commit ed8b1d6d2c741ab26d60d499d7fbb7ac801f0f51 ]

A slave timer element also unlinks at snd_timer_stop() but it takes
only slave_active_lock.  When a slave is assigned to a master,
however, this may become a race against the master's interrupt
handling, eventually resulting in a list corruption.  The actual bug
could be seen with a syzkaller fuzzer test case in BugLink below.

As a fix, we need to take timeri->timer->lock when timer isn't NULL,
i.e. assigned to a master, while the assignment to a master itself is
protected by slave_active_lock.

BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.com
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: timer: Fix wrong instance passed to slave callbacks

2016-03-04T15:18:38+00:00

[ Upstream commit 117159f0b9d392fb433a7871426fad50317f06f7 ]

In snd_timer_notify1(), the wrong timer instance was passed for slave
ccallback function.  This leads to the access to the wrong data when
an incompatible master is handled (e.g. the master is the sequencer
timer and the slave is a user timer), as spotted by syzkaller fuzzer.

This patch fixes that wrong assignment.

BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.com
Reported-by: Dmitry Vyukov 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin