linux-stable.git/sound, branch v4.8.2

ALSA: usb-line6: use the same declaration as definition in header for MIDI manufacturer ID

2016-10-16T16:03:38+00:00

commit 8da08ca03b73593d5299893bf29fc08569c3fb5f upstream.

Currently, usb-line6 module exports an array of MIDI manufacturer ID and
usb-pod module uses it. However, the declaration is not the definition in
common header. The difference is explicit length of array. Although
compiler calculates it and everything goes well, it's better to use the
same representation between definition and declaration.

This commit fills the length of array for usb-line6 module. As a small
good sub-effect, this commit suppress below warnings from static analysis
by sparse v0.5.0.

sound/usb/line6/driver.c:274:43: error: cannot size expression
sound/usb/line6/driver.c:275:16: error: cannot size expression
sound/usb/line6/driver.c:276:16: error: cannot size expression
sound/usb/line6/driver.c:277:16: error: cannot size expression

Fixes: 705ececd1c60 ("Staging: add line6 usb driver")
Signed-off-by: Takashi Sakamoto 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

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

2016-10-16T16:03:38+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 
Signed-off-by: Greg Kroah-Hartman

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

2016-10-16T16:03:38+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: Greg Kroah-Hartman

ALSA: hda - Add the top speaker pin config for HP Spectre x360

2016-10-07T13:03:20+00:00

commit 0eec880966e77bdbee0112989a2be67d92e39929 upstream.

HP Spectre x360 with CX20724 codec has two speaker outputs while the
BIOS sets up only the bottom one (NID 0x17) and disables the top one
(NID 0x1d).

This patch adds a fixup simply defining the proper pincfg for NID 0x1d
so that the top speaker works as is.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=169071
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Fix headset mic detection problem for several Dell laptops

2016-10-07T13:03:20+00:00

commit 3f640970a41429f0a076c01270bbd014c9eae61c upstream.

One of the laptops has the codec ALC256 on it, applying the
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem, the rest
of laptops have the codec ALC295 on them, they are similar to machines
with ALC225, applying the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE can fix
the problem.

Signed-off-by: Hui Wang 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Adding one more ALC255 pin definition for headset problem

2016-10-07T13:03:20+00:00

commit 392c9da24a994f238c5d7ea611c6245be4617014 upstream.

We have two new Dell laptop models, they have the same ALC255 pin
definition, but not in the pin quirk table yet, as a result, the
headset microphone can't work. After adding the definition in the
table, the headset microphone works well.

Signed-off-by: Hui Wang 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: rawmidi: Fix possible deadlock with virmidi registration

2016-09-08T08:45:20+00:00

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

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

2016-09-08T08:45:05+00:00

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

ALSA: timer: fix NULL pointer dereference in read()/ioctl() race

2016-09-02T13:13:08+00:00

I got this with syzkaller:

    ==================================================================
    BUG: KASAN: null-ptr-deref on address 0000000000000020
    Read of size 32 by task syz-executor/22519
    CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2
    014
     0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
     ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
     ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
    Call Trace:
     [] dump_stack+0x83/0xb2
     [] kasan_report_error+0x41f/0x4c0
     [] kasan_report+0x34/0x40
     [] ? snd_timer_user_read+0x554/0x790
     [] check_memory_region+0x13e/0x1a0
     [] kasan_check_read+0x11/0x20
     [] snd_timer_user_read+0x554/0x790
     [] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
     [] ? proc_fault_inject_write+0x1c1/0x250
     [] ? next_tgid+0x2a0/0x2a0
     [] ? do_group_exit+0x108/0x330
     [] ? fsnotify+0x72a/0xca0
     [] __vfs_read+0x10e/0x550
     [] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
     [] ? do_sendfile+0xc50/0xc50
     [] ? __fsnotify_update_child_dentry_flags+0x60/0x60
     [] ? kcov_ioctl+0x56/0x190
     [] ? common_file_perm+0x2e2/0x380
     [] ? __fsnotify_parent+0x5e/0x2b0
     [] ? security_file_permission+0x86/0x1e0
     [] ? rw_verify_area+0xe5/0x2b0
     [] vfs_read+0x115/0x330
     [] SyS_read+0xd1/0x1a0
     [] ? vfs_write+0x4b0/0x4b0
     [] ? __this_cpu_preempt_check+0x1c/0x20
     [] ? __context_tracking_exit.part.4+0x3a/0x1e0
     [] ? vfs_write+0x4b0/0x4b0
     [] do_syscall_64+0x1c4/0x4e0
     [] ? syscall_return_slowpath+0x16c/0x1d0
     [] entry_SYSCALL64_slow_path+0x25/0x25
    ==================================================================

There are a couple of problems that I can see:

 - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
   tu->queue/tu->tqueue to NULL on memory allocation failure, so read()
   would get a NULL pointer dereference like the above splat

 - the same ioctl() can free tu->queue/to->tqueue which means read()
   could potentially see (and dereference) the freed pointer

We can fix both by taking the ioctl_lock mutex when dereferencing
->queue/->tqueue, since that's always held over all the ioctl() code.

Just looking at the code I find it likely that there are more problems
here such as tu->qhead pointing outside the buffer if the size is
changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.

Signed-off-by: Vegard Nossum 
Cc: 
Signed-off-by: Takashi Iwai

ALSA: fireworks: accessing to user space outside spinlock

2016-08-31T14:17:15+00:00

In hwdep interface of fireworks driver, accessing to user space is in a
critical section with disabled local interrupt. Depending on architecture,
accessing to user space can cause page fault exception. Then local
processor stores machine status and handles the synchronous event. A
handler corresponding to the event can call task scheduler to wait for
preparing pages. In a case of usage of single core processor, the state to
disable local interrupt is worse because it don't handle usual interrupts
from hardware.

This commit fixes this bug, performing the accessing outside spinlock. This
commit also gives up counting the number of queued response messages to
simplify ring-buffer management.

Reported-by: Vaishali Thakkar 
Cc: stable@vger.kernel.org
Fixes: 555e8a8f7f14('ALSA: fireworks: Add command/response functionality into hwdep interface')
Signed-off-by: Takashi Sakamoto 
Signed-off-by: Takashi Iwai