The commit [7f0973e9: ALSA: seq: Fix lockdep warnings due to
double mutex locks] split the management of two linked lists (source
and destination) into two individual calls for avoiding the AB/BA
deadlock.  However, this may leave the possible double deletion of one
of two lists when the counterpart is being deleted concurrently.
It ends up with a list corruption, as revealed by syzkaller fuzzer.

This patch fixes it by checking the list emptiness and skipping the
deletion and the following process.

BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com
Fixes: 7f0973e9 ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks)
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Tested-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When multiple concurrent writes happen on the ALSA sequencer device
right after the open, it may try to allocate vmalloc buffer for each
write and leak some of them.  It's because the presence check and the
assignment of the buffer is done outside the spinlock for the pool.

The fix is to move the check and the assignment into the spinlock.

(The current implementation is suboptimal, as there can be multiple
 unnecessary vmallocs because the allocation is done before the check
 in the spinlock.  But the pool size is already checked beforehand, so
 this isn't a big problem; that is, the only possible path is the
 multiple writes before any pool assignment, and practically seen, the
 current coverage should be "good enough".)

The issue was triggered by syzkaller fuzzer.

BugLink: http://lkml.kernel.org/r/CACT4Y+bSzazpXNvtAr=WXaL8hptqjHwqEyFA+VN2AWEx=aurkg@mail.gmail.comReported-by: NDmitry Vyukov <dvyukov@google.com>
Tested-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The port subscription code uses double mutex locks for source and
destination ports, and this may become racy once when wrongly set up.
It leads to lockdep warning splat, typically triggered by fuzzer like
syzkaller, although the actual deadlock hasn't been seen, so far.

This patch simplifies the handling by reducing to two single locks, so
that no lockdep warning will be trigger any longer.

By splitting to two actions, a still-in-progress element shall be
added in one list while handling another.  For ignoring this element,
a new check is added in deliver_to_subscribers().

Along with it, the code to add/remove the subscribers list element was
cleaned up and refactored.

BugLink: http://lkml.kernel.org/r/CACT4Y+aKQXV7xkBW9hpQbzaDO7LrUvohxWh-UwMxXjDy-yBD=A@mail.gmail.comReported-by: NDmitry Vyukov <dvyukov@google.com>
Tested-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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
 [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [<ffffffff84f80bd5>] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136
 [<ffffffff84fdb3c1>] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [<ffffffff84f87ed9>] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223
 [<ffffffff84f89fd3>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273
 [<ffffffff817b0323>] __vfs_write+0x113/0x480 fs/read_write.c:528
 [<ffffffff817b1db7>] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [<ffffffff817b50a1>] SyS_write+0x111/0x220 fs/read_write.c:616
 [<ffffffff86336c36>] 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
 [<ffffffff82be2c0d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [<ffffffff81355139>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [<ffffffff81355369>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [<ffffffff8527e69a>] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133
 [<ffffffff8527e851>] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163
 [<ffffffff852d9046>] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185
 [<     inline     >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150
 [<ffffffff85285a0b>] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252
 [<ffffffff85287b73>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302
 [<ffffffff817ba5f3>] __vfs_write+0x113/0x480 fs/read_write.c:528
 [<ffffffff817bc087>] vfs_write+0x167/0x4a0 fs/read_write.c:577
 [<     inline     >] SYSC_write fs/read_write.c:624
 [<ffffffff817bf371>] SyS_write+0x111/0x220 fs/read_write.c:616
 [<ffffffff86660276>] 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.comReported-by: NDmitry Vyukov <dvyukov@google.com>
Tested-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA sequencer may open/close and control ALSA timer instance
dynamically either via sequencer events or direct ioctls.  These are
done mostly asynchronously, and it may call still some timer action
like snd_timer_start() while another is calling snd_timer_close().
Since the instance gets removed by snd_timer_close(), it may lead to
a use-after-free.

This patch tries to address such a race by protecting each
snd_timer_*() call via the existing spinlock and also by avoiding the
access to timer during close call.

BugLink: http://lkml.kernel.org/r/CACT4Y+Z6RzW5MBr-HUdV-8zwg71WQfKTdPpYGvOeS7v4cyurNQ@mail.gmail.comReported-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The virmidi driver has an open race at closing its assigned rawmidi
device, and this may lead to use-after-free in
snd_seq_deliver_single_event().

Plug the hole by properly protecting the linked list deletion and
calling in the right order in snd_virmidi_input_close().

BugLink: http://lkml.kernel.org/r/CACT4Y+Zd66+w12fNN85-425cVQT=K23kWbhnCEcMB8s3us-Frw@mail.gmail.comReported-by: NDmitry Vyukov <dvyukov@google.com>
Tested-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA OSS sequencer spews a kernel error message ("ALSA: seq_oss: too
many applications") when user-space tries to open more than the
limit.  This means that it can easily fill the log buffer.

Since it's merely a normal error, it's safe to suppress it via
pr_debug() instead.

Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA sequencer OSS emulation code has a sanity check for currently
opened devices, but there is a thinko there, eventually it spews
warnings and skips the operation wrongly like:
  WARNING: CPU: 1 PID: 7573 at sound/core/seq/oss/seq_oss_synth.c:311

Fix this off-by-one error.
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This reverts one hunk of
commit ef44a1ec ("ALSA: sound/core: use memdup_user()"), which
replaced a number of kmalloc followed by memcpy with memdup calls.

In this case, we are copying from a struct snd_seq_port_info32 to a
struct snd_seq_port_info, but the latter is 4 bytes longer than the
32-bit version, so we need to separate kmalloc and copy calls.

Fixes: ef44a1ec ('ALSA: sound/core: use memdup_user()')
Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

ALSA sequencer code has an open race between the timer setup ioctl and
the close of the client.  This was triggered by syzkaller fuzzer, and
a use-after-free was caught there as a result.

This patch papers over it by adding a proper queue->timer_mutex lock
around the timer-related calls in the relevant code path.
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Tested-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_seq_ioctl_remove_events() calls snd_seq_fifo_clear()
unconditionally even if there is no FIFO assigned, and this leads to
an Oops due to NULL dereference.  The fix is just to add a proper NULL
check.
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Tested-by: NDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The ALSA PCM, mixer and sequencer OSS emulations provide the 32bit
compatible ioctl, but they just call the 64bit native ioctl as is.
Although this works in most cases, passing the argument value as-is
isn't guaranteed to work on all architectures.  We need to convert it
via compat_ptr() instead.

This patch addresses the missing conversions.  Since all relevant
ioctls in these functions take the argument as a pointer, we do the
pointer conversion in each compat_ioctl and pass it as a 64bit value
to the native ioctl.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The snd_rawmidi_global_ops structures are never modified, so declare them
as const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_seq_oss_readq_put_event() seems to be missing a memory barrier which
might cause the waker to not notice the waiter and miss sending a
wake_up as in the following figure.

    snd_seq_oss_readq_put_event		    snd_seq_oss_readq_wait
------------------------------------------------------------------------
					/* wait_event_interruptible_timeout */
					 /* __wait_event_interruptible_timeout */
					  /* ___wait_event */
					  for (;;) {									 prepare_to_wait_event(&wq, &__wait,
					    state);
spin_lock_irqsave(&q->lock, flags);
if (waitqueue_active(&q->midi_sleep))
/* The CPU might reorder the test for
   the waitqueue up here, before
   prior writes complete */
					  if ((q->qlen>0 || q->head==q->tail)
					  ...
					  __ret = schedule_timeout(__ret)
if (q->qlen >= q->maxlen - 1) {
memcpy(&q->q[q->tail], ev, sizeof(*ev));
q->tail = (q->tail + 1) % q->maxlen;
q->qlen++;
------------------------------------------------------------------------

There are two other place in sound/core/seq/oss/ which have similar
code.  The attached patch removes the call to waitqueue_active() leaving
just wake_up() behind.  This fixes the problem because the call to
spin_lock_irqsave() in wake_up() will be an ACQUIRE operation.

I found this issue when I was looking through the linux source code
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c  (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: NKosuke Tatsukawa <tatsu@ab.jp.nec.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There are a few leftover CONFIG_PROC_FS forgotten to replace with
CONFIG_SND_PROC_FS.

Fixes: cd6a6503 ('ALSA: replace CONFIG_PROC_FS with CONFIG_SND_PROC_FS')
Reported-by: NJim Davis <jim.epost@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We may disable proc fs only for sound part, to reduce ALSA
memory footprint. So add CONFIG_SND_PROC_FS and replace the
old CONFIG_PROC_FSs in alsa code.

With sound proc fs disabled, we can save about 9KB memory
size on X86_64 platform.
Signed-off-by: NJie Yang <yang.jie@intel.com>
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Minor cleanups of Makefile to build some codes conditionally so that
a few ifdefs can be reduced.
Acked-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

So far we've ignored the errors at creating proc files in many places.
But they should be rather treated seriously.

Also, by assuring the error handling, we can get rid of superfluous
snd_info_free_entry() calls as they will be removed by the parent in
the caller side.

This patch fixes the missing error checks and reduces the superfluous
free calls.
Acked-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The returned value of 'get/seq client pool' operation has zeroed value
for its client ID, against requested client ID.

This commit fix the bug by filling it with index value of referred
client object.
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the sequencer driver is built in kernel, it may panic at boot
because of the uninitialized snd_seq_bus_type.  Initialize it properly
via subsys_initcall() instead of module_init() to assure that the bus
is registered beforehand.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Fixes: 7c37ae5c ('ALSA: seq: Rewrite sequencer device binding with standard bus')
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The kernel memory allocators already report the errors when the
requested allocation fails, thus we don't need to warn it again in
each caller side.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The kernel memory allocators already report the errors when the
requested allocation fails, thus we don't need to warn it again in
each caller side.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The autoload lock became already superfluous due to the recent rework
of autoload code.  Let's drop them now.  This allows us to simplify a
few codes nicely.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch moves the driver object initialization and allocation to
each driver's module init/exit code like other normal drivers.  The
snd_seq_driver struct is now published in seq_device.h, and each
driver is responsible to define it with proper driver attributes
(name, probe and remove) with snd_seq_driver specific attributes as id
and argsize fields.  The helper functions snd_seq_driver_register(),
snd_seq_driver_unregister() and module_snd_seq_driver() are used for
simplifying codes.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use const string pointer instead of copying the id string to each
object.  Also drop the status and list fields of snd_seq_device struct
that are no longer used.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We've used the old house-made code for binding the sequencer device
and driver.  This can be far better implemented with the standard
bus nowadays.

This patch refactors the whole sequencer binding code with the bus
/sys/bus/snd_seq.  The devices appear as id-card-device on this bus
and are bound with the drivers corresponding to the given id like the
former implementation.  The module autoload is also kept like before.

There is no change in API functions by this patch, and almost all
transitions are kept inside seq_device.c.  The proc file output will
change slightly but kept compatible as much as possible.

Further integration works will follow in later patches.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... to follow the standard coding style.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Smatch complains that "control" is user specifigy and needs to be
capped.  The call tree to understand this warning is quite long.

snd_seq_write()  <-- get the event from the user
  snd_seq_client_enqueue_event()
    snd_seq_deliver_event()
      deliver_to_subscribers()
        snd_seq_deliver_single_event()
          snd_opl3_oss_event_input()
            snd_midi_process_event()
              do_control()
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Now that all callers have been replaced with
snd_device_register_for_dev(), let's drop the obsolete device
registration code and concentrate only on the code handling struct
device directly.  That said,

- remove the old snd_device_register(),
- rename snd_device_register_for_dev() with snd_device_register(),
- drop superfluous arguments from snd_device_register(),
- change snd_unregister_device() to pass the device pointer directly
Reviewed-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Like the previous change for the timer device, this patch changes the
device management for the ALSA sequencer device using the struct
device directly.
Reviewed-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Due to SNDRV_SEQ_ADDRESS_BROADCAST, not all 256 port number values can
be used.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the last subscriber to a "Through" port has been removed, the
subscribed destination ports might still be active, so it would be
wrong to send "all sounds off" and "reset controller" events to them.
The proper place for such a shutdown would be the closing of the actual
MIDI port (and close_substream() in rawmidi.c already can do this).

This also fixes a deadlock when dummy_unuse() tries to send events to
its own port that is already locked because it is being freed.
Reported-by: NPeter Billam <peter@www.pjb.com.au>
Cc: <stable@vger.kernel.org>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The snd_midi_event_free() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The functions snd_seq_oss_timer_delete() and vunmap() perform also input
parameter validation. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Since we're calling request_module() asynchronously now, we can get
rid of the autoload lock in snd_seq_device_register_driver(), as well
as in the snd-seq driver registration itself.  This enables the
automatic loading of dependent sequencer modules, such as
snd-seq-virmidi from snd-emu10k1-synth.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Currently the sequencer module binding is performed independently from
the card module itself.  The reason behind it is to keep the sequencer
stuff optional and allow the system running without it (e.g. for using
PCM or rawmidi only).  This works in most cases, but a remaining
problem is that the binding isn't done automatically when a new driver
module is probed.  Typically this becomes visible when a hotplug
driver like usb audio is used.

This patch tries to address this and other potential issues.  First,
the seq-binder (seq_device.c) tries to load a missing driver module at
creating a new device object.  This is done asynchronously in a workq
for avoiding the deadlock (modprobe call in module init path).

This action, however, should be enabled only when the sequencer stuff
was already initialized, i.e. snd-seq module was already loaded.  For
that, a new function, snd_seq_autoload_init() is introduced here; this
clears the blocking of autoloading, and also tries to load all pending
driver modules.
Reported-by: NAdam Goode <agoode@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

... just to robustify for races.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>