linux.git/sound/core, branch v4.9

ALSA: info: Return error for invalid read/write

2016-11-08T13:37:26+00:00

Currently the ALSA proc handler allows read or write even if the proc
file were write-only or read-only.  It's mostly harmless, does thing
but allocating memory and ignores the input/output.  But it doesn't
tell user about the invalid use, and it's confusing and inconsistent
in comparison with other proc files.

This patch adds some sanity checks and let the proc handler returning
an -EIO error when the invalid read/write is performed.

Cc:  # v4.2+
Signed-off-by: Takashi Iwai

ALSA: info: Limit the proc text input size

2016-11-08T12:16:40+00:00

The ALSA proc handler allows currently the write in the unlimited size
until kmalloc() fails.  But basically the write is supposed to be only
for small inputs, mostly for one line inputs, and we don't have to
handle too large sizes at all.  Since the kmalloc error results in the
kernel warning, it's better to limit the size beforehand.

This patch adds the limit of 16kB, which must be large enough for the
currently existing code.

Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Takashi Iwai

ALSA: seq: Fix time account regression

2016-10-25T14:00:46+00:00

The recent rewrite of the sequencer time accounting using timespec64
in the commit [3915bf294652: ALSA: seq_timer: use monotonic times
internally] introduced a bad regression.  Namely, the time reported
back doesn't increase but goes back and forth.

The culprit was obvious: the delta is stored to the result (cur_time =
delta), instead of adding the delta (cur_time += delta)!

Let's fix it.

Fixes: 3915bf294652 ('ALSA: seq_timer: use monotonic times internally')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571
Reported-by: Yves Guillemot 
Cc:  # v4.8+
Signed-off-by: Takashi Iwai

ALSA: seq: fix passing wrong pointer in function call of compatibility layer

2016-10-12T18:09:36+00:00

This commit is a fix for Linux 4.9-rc1.

In former commit, a function call of compatibility layer for ALSA sequencer
core was obsoleted by an alternative. Although, the alternative gets a
pointer to kernel stack due to mis-programming. As a result, ALSA sequencer
core unexpectedly refers over kernel stack.

Reported-by: Dan Carpenter 
Fixes: 8ce8eb601c71 ("ALSA: seq: add an alternative way to handle ioctl requests")
Signed-off-by: Takashi Sakamoto 
Signed-off-by: Takashi Iwai

ALSA: compress: fix some missing and misplaced \n in messages

2016-09-16T17:24:13+00:00

Fix a missing \n in a pr_debug message and move the \n to the end
of a pr_err message.

Signed-off-by: Colin Ian King 
Signed-off-by: Takashi Iwai

ALSA: seq: fix to copy from/to user space

2016-09-13T13:45:29+00:00

When checking value of request for copy operation, current implementation
compares shifted value to macros, while these macros are already shifted.
As a result, it never performs to copy from/to user space.

This commit fixes the bug.

Fixes: 8ce8eb601c71('ALSA: seq: add an alternative way to handle ioctl requests'
Signed-off-by: Takashi Sakamoto 
Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2016-09-11T07:33:12+00:00

Back-merge from for-linus just to make the further development easier.

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: pcm: Fix avail to return error if stream is suspended

2016-09-06T10:10:29+00:00

When the stream is in suspended state some applications wait
on "Stream Pipe Error" in response to snd_pcm_avail call to
resume the stream.

In the current implementation snd_pcm_avail() returns zero
when the stream is in suspended state. This causes application
to enter in infinite loop for frames to be available.

"Stream pipe Error" code is getting returned for read/write
call when the stream is in suspended state. Similarly update
snd_pcm_avail to return -ESTRPIPE.

Signed-off-by: Jeeja KP 
Signed-off-by: Takashi Iwai