kernel.git/sound/core/seq/seq_device.c, branch linux-4.1.y

ALSA: seq: Cancel pending autoload work at unbinding device

2017-12-07T02:20:06Z

[ Upstream commit fc27fe7e8deef2f37cba3f2be2d52b6ca5eb9d57 ] ALSA sequencer core has a mechanism to load the enumerated devices automatically, and it's performed in an off-load work. This seems causing some race when a sequencer is removed while the pending autoload work is running. As syzkaller spotted, it may lead to some use-after-free: BUG: KASAN: use-after-free in snd_rawmidi_dev_seq_free+0x69/0x70 sound/core/rawmidi.c:1617 Write of size 8 at addr ffff88006c611d90 by task kworker/2:1/567 CPU: 2 PID: 567 Comm: kworker/2:1 Not tainted 4.13.0+ #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: events autoload_drivers Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x192/0x22c lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x230/0x340 mm/kasan/report.c:409 __asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435 snd_rawmidi_dev_seq_free+0x69/0x70 sound/core/rawmidi.c:1617 snd_seq_dev_release+0x4f/0x70 sound/core/seq_device.c:192 device_release+0x13f/0x210 drivers/base/core.c:814 kobject_cleanup lib/kobject.c:648 [inline] kobject_release lib/kobject.c:677 [inline] kref_put include/linux/kref.h:70 [inline] kobject_put+0x145/0x240 lib/kobject.c:694 put_device+0x25/0x30 drivers/base/core.c:1799 klist_devices_put+0x36/0x40 drivers/base/bus.c:827 klist_next+0x264/0x4a0 lib/klist.c:403 next_device drivers/base/bus.c:270 [inline] bus_for_each_dev+0x17e/0x210 drivers/base/bus.c:312 autoload_drivers+0x3b/0x50 sound/core/seq_device.c:117 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231 kthread+0x324/0x3f0 kernel/kthread.c:231 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425 The fix is simply to assure canceling the autoload work at removing the device. Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: seq: Fix init order of snd_seq_device stuff

2015-03-11T11:53:52Z

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: Fengguang Wu Fixes: 7c37ae5c625a ('ALSA: seq: Rewrite sequencer device binding with standard bus') Signed-off-by: Takashi Iwai

ALSA: seq: Drop snd_seq_autoload_lock() and _unlock()

2015-02-12T13:42:31Z

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: Takashi Iwai

ALSA: seq: Define driver object in each driver

2015-02-12T13:15:54Z

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: Takashi Iwai

ALSA: seq: Clean up device and driver structs

2015-02-12T13:13:47Z

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: Takashi Iwai

ALSA: seq: Rewrite sequencer device binding with standard bus

2015-02-12T10:35:11Z

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: Takashi Iwai

ALSA: seq: Don't compile snd_seq_device_load_drivers() for built-in

2015-02-12T10:35:11Z

Signed-off-by: Takashi Iwai

ALSA: seq: Move EXPORT_SYMBOL() after each function

2015-02-12T10:35:11Z

... to follow the standard coding style. Signed-off-by: Takashi Iwai

Subject: ALSA: seq: Remove autoload locks in driver registration

2014-10-18T18:25:19Z

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: Takashi Iwai

ALSA: seq: bind seq driver automatically

2014-10-18T18:25:12Z

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