linux-stable.git/include/sound, branch linux-3.2.y

ALSA: seq: Avoid invalid lockdep class warning

2018-01-01T20:51:02+00:00

commit 3510c7aa069aa83a2de6dab2b41401a198317bdc upstream.

The recent fix for adding rwsem nesting annotation was using the given
"hop" argument as the lock subclass key.  Although the idea itself
works, it may trigger a kernel warning like:
  BUG: looking up invalid subclass: 8
  ....
since the lockdep has a smaller number of subclasses (8) than we
currently allow for the hops there (10).

The current definition is merely a sanity check for avoiding the too
deep delivery paths, and the 8 hops are already enough.  So, as a
quick fix, just follow the max hops as same as the max lockdep
subclasses.

Fixes: 1f20f9ff57ca ("ALSA: seq: Fix nested rwsem annotation for lockdep splat")
Reported-by: syzbot 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: timer: Limit max instances per timer

2018-01-01T20:51:02+00:00

commit 9b7d869ee5a77ed4a462372bb89af622e705bfb8 upstream.

Currently we allow unlimited number of timer instances, and it may
bring the system hogging way too much CPU when too many timer
instances are opened and processed concurrently.  This may end up with
a soft-lockup report as triggered by syzkaller, especially when
hrtimer backend is deployed.

Since such insane number of instances aren't demanded by the normal
use case of ALSA sequencer and it merely  opens a risk only for abuse,
this patch introduces the upper limit for the number of instances per
timer backend.  As default, it's set to 1000, but for the fine-grained
timer like hrtimer, it's set to 100.

Reported-by: syzbot
Tested-by: Jérôme Glisse 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ALSA: seq: Fix copy_from_user() call inside lock

2018-01-01T20:50:56+00:00

commit 5803b023881857db32ffefa0d269c90280a67ee0 upstream.

The event handler in the virmidi sequencer code takes a read-lock for
the linked list traverse, while it's calling snd_seq_dump_var_event()
in the loop.  The latter function may expand the user-space data
depending on the event type.  It eventually invokes copy_from_user(),
which might be a potential dead-lock.

The sequencer core guarantees that the user-space data is passed only
with atomic=0 argument, but snd_virmidi_dev_receive_event() ignores it
and always takes read-lock().  For avoiding the problem above, this
patch introduces rwsem for non-atomic case, while keeping rwlock for
atomic case.

Also while we're at it: the superfluous irq flags is dropped in
snd_virmidi_input_open().

Reported-by: Jia-Ju Bai 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: rawmidi: Make snd_rawmidi_transmit() race-free

2016-02-27T14:28:46+00:00

commit 06ab30034ed9c200a570ab13c017bde248ddb2a6 upstream.

A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by
syzkaller fuzzer:
  WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
 [] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
 [] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
 [] __vfs_write+0x113/0x480 fs/read_write.c:528
 [] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [] SyS_write+0x111/0x220 fs/read_write.c:616
 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

Also a similar warning is found but in another path:
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
 [] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
 [] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
 [] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
 [] __vfs_write+0x113/0x480 fs/read_write.c:528
 [] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [] SyS_write+0x111/0x220 fs/read_write.c:616
 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185

In the former case, the reason is that virmidi has an open code
calling snd_rawmidi_transmit_ack() with the value calculated outside
the spinlock.   We may use snd_rawmidi_transmit() in a loop just for
consuming the input data, but even there, there is a race between
snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack().

Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and
snd_rawmidi_tranmit_ack() separately without protection, so they are
racy as well.

The patch tries to address these issues by the following ways:
- Introduce the unlocked versions of snd_rawmidi_transmit_peek() and
  snd_rawmidi_transmit_ack() to be called inside the explicit lock.
- Rewrite snd_rawmidi_transmit() to be race-free (the former case).
- Make the split calls (the latter case) protected in the rawmidi spin
  lock.

BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com
BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.com
Reported-by: Dmitry Vyukov 
Tested-by: Dmitry Vyukov 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ALSA: tlv: add DECLARE_TLV_DB_RANGE()

2016-01-22T21:40:04+00:00

commit bf1d1c9b6179faa3bc32cee882462bc8eebde25d upstream.

Add a DECLARE_TLV_DB_RANGE() macro so that dB range information
can be specified without having to count the items manually for
TLV_DB_RANGE_HEAD().

Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: tlv: compute TLV_*_ITEM lengths automatically

2016-01-22T21:40:04+00:00

commit b5b9eb546762c4015c67c31364a6ec6f83fd2ada upstream.

Add helper macros with a little bit of preprocessor magic to
automatically compute the length of a TLV item.  This lets us avoid
having to compute this by hand, and will allow to use items that do
not use a fixed length.

Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ASoC: wm8904: Correct number of EQ registers

2015-11-17T15:54:44+00:00

commit 97aff2c03a1e4d343266adadb52313613efb027f upstream.

There are 24 EQ registers not 25, I suspect this bug came about because
the registers start at EQ1 not zero. The bug is relatively harmless as
the extra register written is an unused one.

Signed-off-by: Charles Keepax 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

ALSA: emu10k1: Emu10k2 32 bit DMA mode

2015-08-06T23:32:08+00:00

commit 7241ea558c6715501e777396b5fc312c372e11d9 upstream.

Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two
modes for DMA. Second mode is useful for 64 bit os with more then 2 GB
of ram (fixes problems with big soundfont loading)

1) 32MB from 2 GB address space using 8192 pages (used now as default)
2) 16MB from 4 GB address space using 4096 pages

Mode is set using HCFG_EXPANDED_MEM flag in HCFG register.
Also format of emu10k2 page table is then different.

Signed-off-by: Peter Zubaj 
Tested-by: Takashi Iwai 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: ak411x: Fix stall in work callback

2015-03-06T00:39:17+00:00

commit 4161b4505f1690358ac0a9ee59845a7887336b21 upstream.

When ak4114 work calls its callback and the callback invokes
ak4114_reinit(), it stalls due to flush_delayed_work().  For avoiding
this, control the reentrance by introducing a refcount.  Also
flush_delayed_work() is replaced with cancel_delayed_work_sync().

The exactly same bug is present in ak4113.c and fixed as well.

Reported-by: Pavel Hofman 
Acked-by: Jaroslav Kysela 
Tested-by: Pavel Hofman 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: snd_ak411{3,4}_reinit were previously using
 flush_delayed_work_sync() rather than flush_delayed_work()]
Signed-off-by: Ben Hutchings

ALSA: control: Protect user controls against concurrent access

2014-07-11T12:33:51+00:00

commit 07f4d9d74a04aa7c72c5dae0ef97565f28f17b92 upstream.

The user-control put and get handlers as well as the tlv do not protect against
concurrent access from multiple threads. Since the state of the control is not
updated atomically it is possible that either two write operations or a write
and a read operation race against each other. Both can lead to arbitrary memory
disclosure. This patch introduces a new lock that protects user-controls from
concurrent access. Since applications typically access controls sequentially
than in parallel a single lock per card should be fine.

Signed-off-by: Lars-Peter Clausen 
Acked-by: Jaroslav Kysela 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings