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

ALSA: seq: Fix race at creating a queue

2017-03-16T02:18:48+00:00

commit 4842e98f26dd80be3623c4714a244ba52ea096a8 upstream.

When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
new queue element to the public list before referencing it.  Thus the
queue might be deleted before the call of snd_seq_queue_use(), and it
results in the use-after-free error, as spotted by syzkaller.

The fix is to reference the queue object at the right time.

Reported-by: Dmitry Vyukov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: seq: Don't handle loop timeout at snd_seq_pool_done()

2017-03-16T02:18:47+00:00

commit 37a7ea4a9b81f6a864c10a7cb0b96458df5310a3 upstream.

snd_seq_pool_done() syncs with closing of all opened threads, but it
aborts the wait loop with a timeout, and proceeds to the release
resource even if not all threads have been closed.  The timeout was 5
seconds, and if you run a crazy stuff, it can exceed easily, and may
result in the access of the invalid memory address -- this is what
syzkaller detected in a bug report.

As a fix, let the code graduate from naiveness, simply remove the loop
timeout.

BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.com
Reported-by: Dmitry Vyukov 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: deleted log statement is slightly different]
Signed-off-by: Ben Hutchings

ALSA: usb-audio: Add QuickCam Communicate Deluxe/S7500 to volume_control_quirks

2017-03-16T02:18:30+00:00

commit 82ffb6fc637150b279f49e174166d2aa3853eaf4 upstream.

The Logitech QuickCam Communicate Deluxe/S7500 microphone fails with the
following warning.

[    6.778995] usb 2-1.2.2.2: Warning! Unlikely big volume range (=3072),
cval->res is probably wrong.
[    6.778996] usb 2-1.2.2.2: [5] FU [Mic Capture Volume] ch = 1, val =
4608/7680/1

Adding it to the list of devices in volume_control_quirks makes it work
properly, fixing related typo.

Signed-off-by: Con Kolivas 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: usb-audio: Fix bogus error return in snd_usb_create_stream()

2017-03-16T02:18:28+00:00

commit 4763601a56f155ddf94ef35fc2c41504a2de15f5 upstream.

The function returns -EINVAL even if it builds the stream properly.
The bogus error code sneaked in during the code refactoring, but it
wasn't noticed until now since the returned error code itself is
ignored in anyway.  Kill it here, but there is no behavior change by
this patch, obviously.

Fixes: e5779998bf8b ('ALSA: usb-audio: refactor code')
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: pcm : Call kill_fasync() in stream lock

2017-02-23T03:51:06+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ALSA: usb-audio: Add quirk for Syntek STK1160

2017-02-23T03:50:55+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: Ben Hutchings

ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variants

2017-02-23T03:50:50+00:00

commit eb1a74b7bea17eea31915c4f76385cefe69d9795 upstream.

The DragonFly quirk added in 42e3121d90f4 ("ALSA: usb-audio: Add a more
accurate volume quirk for AudioQuest DragonFly") applies a custom dB map
on the volume control when its range is reported as 0..50 (0 .. 0.2dB).

However, there exists at least one other variant (hw v1.0c, as opposed
to the tested v1.2) which reports a different non-sensical volume range
(0..53) and the custom map is therefore not applied for that device.

This results in all of the volume change appearing close to 100% on
mixer UIs that utilize the dB TLV information.

Add a fallback case where no dB TLV is reported at all if the control
range is not 0..50 but still 0..N where N <= 1000 (3.9 dB). Also
restrict the quirk to only apply to the volume control as there is also
a mute control which would match the check otherwise.

Fixes: 42e3121d90f4 ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly")
Signed-off-by: Anssi Hannula 
Reported-by: David W 
Tested-by: David W 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: keep using dev_info()]
Signed-off-by: Ben Hutchings

ALSA: ali5451: Fix out-of-bound position reporting

2017-02-23T03:50:50+00:00

commit db68577966abc1aeae4ec597b3dcfa0d56e92041 upstream.

The pointer callbacks of ali5451 driver may return the value at the
boundary occasionally, and it results in the kernel warning like
  snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024

It seems that folding the position offset is enough for fixing the
warning and no ill-effect has been seen by that.

Reported-by: Enrico Mioso 
Tested-by: Enrico Mioso 
Signed-off-by: Takashi Iwai 
Signed-off-by: Ben Hutchings

ALSA: rawmidi: Fix possible deadlock with virmidi registration

2016-11-20T01:01:37+00:00

commit 816f318b2364262a51024096da7ca3b84e78e3b5 upstream.

When a seq-virmidi driver is initialized, it registers a rawmidi
instance with its callback to create an associated seq kernel client.
Currently it's done throughly in rawmidi's register_mutex context.
Recently it was found that this may lead to a deadlock another rawmidi
device that is being attached with the sequencer is accessed, as both
open with the same register_mutex.  This was actually triggered by
syzkaller, as Dmitry Vyukov reported:

======================================================
 [ INFO: possible circular locking dependency detected ]
 4.8.0-rc1+ #11 Not tainted
 -------------------------------------------------------
 syz-executor/7154 is trying to acquire lock:
  (register_mutex#5){+.+.+.}, at: [] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341

 but task is already holding lock:
  (&grp->list_mutex){++++.+}, at: [] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 (&grp->list_mutex){++++.+}:
    [] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
    [] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
    [<     inline     >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
    [] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
    [] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
    [] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
    [] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297
    [<     inline     >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383
    [] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
    [] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
    [] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
    [<     inline     >] __snd_device_register sound/core/device.c:162
    [] snd_device_register_all+0xad/0x110 sound/core/device.c:212
    [] snd_card_register+0xef/0x6c0 sound/core/init.c:749
    [] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
    [] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564
    ......

 -> #0 (register_mutex#5){+.+.+.}:
    [<     inline     >] check_prev_add kernel/locking/lockdep.c:1829
    [<     inline     >] check_prevs_add kernel/locking/lockdep.c:1939
    [<     inline     >] validate_chain kernel/locking/lockdep.c:2266
    [] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
    [] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
    [<     inline     >] __mutex_lock_common kernel/locking/mutex.c:521
    [] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
    [] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
    [] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
    [<     inline     >] subscribe_port sound/core/seq/seq_ports.c:427
    [] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
    [] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
    [] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
    [] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
    [] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
    [] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
    [] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
    [] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
    [] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
    [] soundcore_open+0x30f/0x640 sound/sound_core.c:639
    ......

 other info that might help us debug this:

 Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&grp->list_mutex);
                                lock(register_mutex#5);
                                lock(&grp->list_mutex);
   lock(register_mutex#5);

 *** DEADLOCK ***
======================================================

The fix is to simply move the registration parts in
snd_rawmidi_dev_register() to the outside of the register_mutex lock.
The lock is needed only to manage the linked list, and it's not
necessarily to cover the whole initialization process.

Reported-by: Dmitry Vyukov 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ALSA: timer: Fix zero-division by continue of uninitialized instance

2016-11-20T01:01:37+00:00

commit 9f8a7658bcafb2a7853f7a2eae8a94e87e6e695b upstream.

When a user timer instance is continued without the explicit start
beforehand, the system gets eventually zero-division error like:

  divide error: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
  CPU: 1 PID: 27320 Comm: syz-executor Not tainted 4.8.0-rc3-next-20160825+ #8
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
   task: ffff88003c9b2280 task.stack: ffff880027280000
   RIP: 0010:[]  [<     inline     >] ktime_divns include/linux/ktime.h:195
   RIP: 0010:[]  [] snd_hrtimer_callback+0x1bc/0x3c0 sound/core/hrtimer.c:62
  Call Trace:
   
   [<     inline     >] __run_hrtimer kernel/time/hrtimer.c:1238
   [] __hrtimer_run_queues+0x325/0xe70 kernel/time/hrtimer.c:1302
   [] hrtimer_interrupt+0x18b/0x420 kernel/time/hrtimer.c:1336
   [] local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:933
   [] smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:957
   [] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:487
   
   .....

Although a similar issue was spotted and a fix patch was merged in
commit [6b760bb2c63a: ALSA: timer: fix division by zero after
SNDRV_TIMER_IOCTL_CONTINUE], it seems covering only a part of
iceberg.

In this patch, we fix the issue a bit more drastically.  Basically the
continue of an uninitialized timer is supposed to be a fresh start, so
we do it for user timers.  For the direct snd_timer_continue() call,
there is no way to pass the initial tick value, so we kick out for the
uninitialized case.

Reported-by: Dmitry Vyukov 
Signed-off-by: Takashi Iwai 
[bwh: Backported to 3.2:
 - Adjust context
 - In _snd_timer_stop(), check the value of 'event' instead of 'stop']
Signed-off-by: Ben Hutchings