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

ALSA: pcm : Call kill_fasync() in stream lock

2017-05-08T05:44:10+00:00

commit 3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4 upstream.

Currently kill_fasync() is called outside the stream lock in
snd_pcm_period_elapsed().  This is potentially racy, since the stream
may get released even during the irq handler is running.  Although
snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
guarantee that the irq handler finishes, thus the kill_fasync() call
outside the stream spin lock may be invoked after the substream is
detached, as recently reported by KASAN.

As a quick workaround, move kill_fasync() call inside the stream
lock.  The fasync is rarely used interface, so this shouldn't have a
big impact from the performance POV.

Ideally, we should implement some sync mechanism for the proper finish
of stream and irq handler.  But this oneliner should suffice for most
cases, so far.

Reported-by: Baozeng Ding 
Signed-off-by: Takashi Iwai 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

ALSA: ppc/awacs: shut up maybe-uninitialized warning

2017-05-08T05:44:10+00:00

commit b268c34e5ee92a4cc3099b0caaf26e6bfbdf0f18 upstream.

The awacs sound driver produces a false-positive warning in ppc64_defconfig:

sound/ppc/awacs.c: In function 'snd_pmac_awacs_init':
include/sound/control.h:219:9: warning: 'master_vol' may be used uninitialized in this function [-Wmaybe-uninitialized]

I haven't come up with a good way to rewrite the code to avoid the
warning, so here is a bad one: I initialize the variable before
the conditionall initialization so gcc no longer has to worry about
it.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: seq: Don't break snd_use_lock_sync() loop by timeout

2017-05-08T05:44:09+00:00

commit 4e7655fd4f47c23e5249ea260dc802f909a64611 upstream.

The snd_use_lock_sync() (thus its implementation
snd_use_lock_sync_helper()) has the 5 seconds timeout to break out of
the sync loop.  It was introduced from the beginning, just to be
"safer", in terms of avoiding the stupid bugs.

However, as Ben Hutchings suggested, this timeout rather introduces a
potential leak or use-after-free that was apparently fixed by the
commit 2d7d54002e39 ("ALSA: seq: Fix race during FIFO resize"):
for example, snd_seq_fifo_event_in() -> snd_seq_event_dup() ->
copy_from_user() could block for a long time, and snd_use_lock_sync()
goes timeout and still leaves the cell at releasing the pool.

For fixing such a problem, we remove the break by the timeout while
still keeping the warning.

Suggested-by: Ben Hutchings 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: seq: Fix race during FIFO resize

2017-04-22T05:15:00+00:00

commit 2d7d54002e396c180db0c800c1046f0a3c471597 upstream.

When a new event is queued while processing to resize the FIFO in
snd_seq_fifo_clear(), it may lead to a use-after-free, as the old pool
that is being queued gets removed.  For avoiding this race, we need to
close the pool to be deleted and sync its usage before actually
deleting it.

The issue was spotted by syzkaller.

Reported-by: Dmitry Vyukov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: seq: Fix racy cell insertions during snd_seq_pool_done()

2017-04-22T05:15:00+00:00

commit c520ff3d03f0b5db7146d9beed6373ad5d2a5e0e upstream.

When snd_seq_pool_done() is called, it marks the closing flag to
refuse the further cell insertions.  But snd_seq_pool_done() itself
doesn't clear the cells but just waits until all cells are cleared by
the caller side.  That is, it's racy, and this leads to the endless
stall as syzkaller spotted.

This patch addresses the racy by splitting the setup of pool->closing
flag out of snd_seq_pool_done(), and calling it properly before
snd_seq_pool_done().

BugLink: http://lkml.kernel.org/r/CACT4Y+aqqy8bZA1fFieifNxR2fAfFQQABcBHj801+u5ePV0URw@mail.gmail.com
Reported-and-tested-by: Dmitry Vyukov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ASoC: cs4270: fix DAPM stream name mismatch

2017-04-18T05:55:47+00:00

commit aa5f920993bda2095952177eea79bc8e58ae6065 upstream.

Mismatching stream names in DAPM route and widget definitions are
causing compilation errors. Fixing these names allows the cs4270
driver to compile and function.

[Errors must be at probe time not compile time -- broonie]

Signed-off-by: Murray Foster 
Acked-by: Paul Handrigan 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ALSA: usb-audio: Add quirk for Syntek STK1160

2017-04-18T05:55:45+00:00

commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream.

The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves
the issue reported on the mailing list
(http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes
bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071).

Signed-off-by: Marcel Hasler 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: oxygen: Fix logical-not-parentheses warning

2017-02-08T08:43:03+00:00

commit 8ec7cfce3762299ae289c384e281b2f4010ae231 upstream.

This fixes the following warning, that is seen with gcc 5.1:
warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses].

Signed-off-by: Tomer Barletz 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

Revert "ALSA: usb-audio: Fix race at stopping the stream"

2017-01-15T14:49:52+00:00

[ Upstream commit f8114f8583bb18a467c04ddc1e8978330e445801 ]

This reverts commit 16200948d8353fe29a473a394d7d26790deae0e7.

The commit was intended to cover the race condition, but it introduced
yet another regression for devices with the implicit feedback, leading
to a kernel panic due to NULL-dereference in an irq context.

As the race condition that was addressed by the commit is very rare
and the regression is much worse, let's revert the commit for rc1, and
fix the issue properly in a later patch.

Fixes: 16200948d835 ("ALSA: usb-audio: Fix race at stopping the stream")
Reported-by: Ioan-Adrian Ratiu 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

ALSA: hiface: Fix M2Tech hiFace driver sampling rate change

2017-01-15T14:49:52+00:00

[ Upstream commit 995c6a7fd9b9212abdf01160f6ce3193176be503 ]

Sampling rate changes after first set one are not reflected to the
hardware, while driver and ALSA think the rate has been changed.

Fix the problem by properly stopping the interface at the beginning of
prepare call, allowing new rate to be set to the hardware. This keeps
the hardware in sync with the driver.

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