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

ALSA: control: Hardening for potential Spectre v1

2018-05-23T01:36:38+00:00

[ Upstream commit 088e861edffb84879cf0c0d1b02eda078c3a0ffe ]

As recently Smatch suggested, a few places in ALSA control core codes
may expand the array directly from the user-space value with
speculation:

  sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd'
  sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd'

Although all these seem doing only the first load without further
reference, we may want to stay in a safer side, so hardening with
array_index_nospec() would still make sense.

In this patch, we put array_index_nospec() to the common
snd_ctl_get_ioff*() helpers instead of each caller.  These helpers are
also referred from some drivers, too, and basically all usages are to
calculate the array index from the user-space value, hence it's better
to cover there.

BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2
Reported-by: Dan Carpenter 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams

2018-05-23T01:36:34+00:00

[ Upstream commit 40cab6e88cb0b6c56d3f30b7491a20e803f948f6 ]

OSS PCM stream management isn't modal but it allows ioctls issued at
any time for changing the parameters.  In the previous hardening
patch ("ALSA: pcm: Avoid potential races between OSS ioctls and
read/write"), we covered these races and prevent the corruption by
protecting the concurrent accesses via params_lock mutex.  However,
this means that some ioctls that try to change the stream parameter
(e.g. channels or format) would be blocked until the read/write
finishes, and it may take really long.

Basically changing the parameter while reading/writing is an invalid
operation, hence it's even more user-friendly from the API POV if it
returns -EBUSY in such a situation.

This patch adds such checks in the relevant ioctls with the addition
of read/write access refcount.

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

ALSA: seq: Avoid invalid lockdep class warning

2017-12-07T02:20:01+00:00

[ Upstream commit 3510c7aa069aa83a2de6dab2b41401a198317bdc ]

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 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: seq: Fix copy_from_user() call inside lock

2017-11-06T04:54:24+00:00

[ Upstream commit 5803b023881857db32ffefa0d269c90280a67ee0 ]

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 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: hda - Fix possible race on regmap bypass flip

2016-07-11T00:19:59+00:00

[ Upstream commit 3194ed497939c6448005542e3ca4fa2386968fa0 ]

HD-audio driver uses regmap cache bypass feature for reading a raw
value without the cache.  But this is racy since both the cached and
the uncached reads may occur concurrently.  The former is done via the
normal control API access while the latter comes from the proc file
read.

Even though the regmap itself has the protection against the
concurrent accesses, the flag set/reset is done without the
protection, so it may lead to inconsistent state of bypass flag that
doesn't match with the current read and occasionally result in a
kernel WARNING like:
  WARNING: CPU: 3 PID: 2731 at drivers/base/regmap/regcache.c:499 regcache_cache_only+0x78/0x93

One way to work around such a problem is to wrap with a mutex.  But in
this case, the solution is simpler: for the uncached read, we just
skip the regmap and directly calls its accessor.  The verb execution
there is protected by itself, so basically it's safe to call
individually.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ALSA: hda - Check the return value from pm_runtime_get/put*()

2016-04-18T12:50:48+00:00

[ Upstream commit fbce23a0b95763dfc4961ce6240e055c39f497ed ]

This patch changes the return type of snd_hdac_power_up/down() and
variants to pass the error code from the underlying
pm_runtime_get/put() calls.  Currently they are ignored, but in most
places, these should be handled properly.

As an example, the regmap handler is updated to check the return value
and accesses the register only when the wakeup succeeds.

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

ALSA: rawmidi: Make snd_rawmidi_transmit() race-free

2016-02-15T20:45:31+00:00

[ Upstream commit 06ab30034ed9c200a570ab13c017bde248ddb2a6 ]

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 
Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin

ASoC: wm8904: Correct number of EQ registers

2015-11-09T22:33:34+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: Greg Kroah-Hartman

ASoC: Add info callback for SX_TLV controls

2015-11-09T22:33:34+00:00

commit 34198710f55b5f359f43e67d9a08fe5aadfbca1b upstream.

SX_TLV controls are intended for situations where the register behind
the control has some non-zero value indicating the minimum gain
and then gains increasing from there and eventually overflowing through
zero.

Currently every CODEC implementing these controls specifies the minimum
as the non-zero value for the minimum and the maximum as the number of
gain settings available.

This means when the info callback subtracts the minimum value from the
maximum value to calculate the number of gain levels available it is
actually under reporting the available levels. This patch fixes this
issue by adding a new snd_soc_info_volsw_sx callback that does not
subtract the minimum value.

Fixes: 1d99f2436d0d ("ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV")
Signed-off-by: Charles Keepax 
Acked-by: Brian Austin 
Tested-by: Brian Austin 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Re-add the lost fake mute support

2015-06-11T09:55:48+00:00

Yet another regression by the transition to regmap cache; for better
usability, we had the fake mute control using the zero amp value for
Conexant codecs, and this was forgotten in the new hda core code.

Since the bits 4-7 are unused for the amp registers (as we follow the
syntax of AMP_GET verb), the bit 4 is now used to indicate the fake
mute.  For setting this flag, snd_hda_codec_amp_update() becomes a
function from a simple macro.  The bonus is that it gained a proper
function description.

Signed-off-by: Takashi Iwai