linux/sound/usb/mixer.c

3962 lines
105 KiB

ALSA: usb-audio: Fix out-of-bound error The snd_usb_copy_string_desc() retrieves the usb string corresponding to the index number through the usb_string(). The problem is that the usb_string() returns the length of the string (>= 0) when successful, but it can also return a negative value about the error case or status of usb_control_msg(). If iClockSource is '0' as shown below, usb_string() will returns -EINVAL. This will result in '0' being inserted into buf[-22], and the following KASAN out-of-bound error message will be output. AudioControl Interface Descriptor: bLength 8 bDescriptorType 36 bDescriptorSubtype 10 (CLOCK_SOURCE) bClockID 1 bmAttributes 0x07 Internal programmable Clock (synced to SOF) bmControls 0x07 Clock Frequency Control (read/write) Clock Validity Control (read-only) bAssocTerminal 0 iClockSource 0 To fix it, check usb_string()'return value and bail out. ================================================================== BUG: KASAN: stack-out-of-bounds in parse_audio_unit+0x1327/0x1960 [snd_usb_audio] Write of size 1 at addr ffff88007e66735a by task systemd-udevd/18376 CPU: 0 PID: 18376 Comm: systemd-udevd Not tainted 4.13.0+ #3 Hardware name: LG Electronics 15N540-RFLGL/White Tip Mountain, BIOS 15N5 Call Trace: dump_stack+0x63/0x8d print_address_description+0x70/0x290 ? parse_audio_unit+0x1327/0x1960 [snd_usb_audio] kasan_report+0x265/0x350 __asan_store1+0x4a/0x50 parse_audio_unit+0x1327/0x1960 [snd_usb_audio] ? save_stack+0xb5/0xd0 ? save_stack_trace+0x1b/0x20 ? save_stack+0x46/0xd0 ? kasan_kmalloc+0xad/0xe0 ? kmem_cache_alloc_trace+0xff/0x230 ? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio] ? usb_audio_probe+0x4de/0xf40 [snd_usb_audio] ? usb_probe_interface+0x1f5/0x440 ? driver_probe_device+0x3ed/0x660 ? build_feature_ctl+0xb10/0xb10 [snd_usb_audio] ? save_stack_trace+0x1b/0x20 ? init_object+0x69/0xa0 ? snd_usb_find_csint_desc+0xa8/0xf0 [snd_usb_audio] snd_usb_mixer_controls+0x1dc/0x370 [snd_usb_audio] ? build_audio_procunit+0x890/0x890 [snd_usb_audio] ? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio] ? kmem_cache_alloc_trace+0xff/0x230 ? usb_ifnum_to_if+0xbd/0xf0 snd_usb_create_mixer+0x25b/0x4b0 [snd_usb_audio] ? snd_usb_create_stream+0x255/0x2c0 [snd_usb_audio] usb_audio_probe+0x4de/0xf40 [snd_usb_audio] ? snd_usb_autosuspend.part.7+0x30/0x30 [snd_usb_audio] ? __pm_runtime_idle+0x90/0x90 ? kernfs_activate+0xa6/0xc0 ? usb_match_one_id_intf+0xdc/0x130 ? __pm_runtime_set_status+0x2d4/0x450 usb_probe_interface+0x1f5/0x440 Cc: <stable@vger.kernel.org> Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-12-04 15:31:48 +09:00
ALSA: usb-audio: don't retry snd_usb_ctl_msg after timeout A few calls to snd_usb_ctl_msg wrap the function in a retry loop. In the worst case, the timeout for snd_usb_ctl_msg is 5 seconds, which when retried 10 times (for example, if a device is removed) could cause a probe to hang for ~50 seconds. Example stack trace from 3.14 which triggered a hung task timeout: Call Trace: [<ffffffffa2c1f720>] ? inet6_set_link_af.part.35+0x12/0x12 [<ffffffffa2c20309>] schedule+0x6e/0x70 [<ffffffffa2c1f81c>] schedule_timeout+0xfc/0x13c [<ffffffffa2667bbc>] ? rcu_read_unlock_sched_notrace+0x17/0x17 [<ffffffffa2c20d68>] __wait_for_common+0x153/0x190 [<ffffffffa2c20d68>] ? __wait_for_common+0x153/0x190 [<ffffffffa26890e5>] ? wake_up_state+0x12/0x12 [<ffffffffa2c20e0e>] wait_for_completion_timeout+0x1d/0x1f [<ffffffffa2a07c70>] usb_start_wait_urb+0x93/0xf1 [<ffffffffa2a07daf>] usb_control_msg+0xe1/0x11d [<ffffffffc02cd254>] snd_usb_ctl_msg+0x9c/0xf1 [snd_usb_audio] [<ffffffffc02ce191>] snd_usb_mixer_set_ctl_value+0x124/0xab1 [snd_usb_audio] [<ffffffffc02ce230>] snd_usb_mixer_set_ctl_value+0x1c3/0xab1 [snd_usb_audio] [<ffffffffc02ce58e>] snd_usb_mixer_set_ctl_value+0x521/0xab1 [snd_usb_audio] [<ffffffffc02cee88>] snd_usb_mixer_add_control+0x36a/0x1264 [snd_usb_audio] [<ffffffffc02cf323>] snd_usb_mixer_add_control+0x805/0x1264 [snd_usb_audio] [<ffffffffa2a06e11>] ? usb_free_urb+0x1a/0x1c [<ffffffffc02cfcf7>] snd_usb_mixer_add_control+0x11d9/0x1264 [snd_usb_audio] [<ffffffffc02d000f>] snd_usb_create_mixer+0xbc/0x286 [snd_usb_audio] [<ffffffffc02cac18>] 0xffffffffc02cac17 [<ffffffffa2a0aaf1>] usb_probe_interface+0x17c/0x21c [<ffffffffa29a65bc>] driver_probe_device+0xae/0x1fa [<ffffffffa29a6767>] __device_attach_driver+0x5f/0x66 [<ffffffffa29a6708>] ? driver_probe_device+0x1fa/0x1fa [<ffffffffa29a4a60>] bus_for_each_drv+0x87/0xaa [<ffffffffa29a688a>] __device_attach+0x9d/0x101 [<ffffffffa29a6913>] device_initial_probe+0x13/0x15 [<ffffffffa29a5ae6>] bus_probe_device+0x33/0x96 [<ffffffffa29a3d19>] device_add+0x328/0x547 [<ffffffffa2a09355>] usb_set_configuration+0x624/0x674 [<ffffffffa2a11949>] generic_probe+0x45/0x77 [<ffffffffa2a0a962>] usb_probe_device+0x2d/0x40 [<ffffffffa29a65bc>] driver_probe_device+0xae/0x1fa [<ffffffffa29a6767>] __device_attach_driver+0x5f/0x66 [<ffffffffa29a6708>] ? driver_probe_device+0x1fa/0x1fa [<ffffffffa29a4a60>] bus_for_each_drv+0x87/0xaa [<ffffffffa29a688a>] __device_attach+0x9d/0x101 [<ffffffffa29a6913>] device_initial_probe+0x13/0x15 [<ffffffffa29a5ae6>] bus_probe_device+0x33/0x96 [<ffffffffa29a3d19>] device_add+0x328/0x547 [<ffffffffa29030bc>] ? add_device_randomness+0x111/0x130 [<ffffffffa2a00967>] usb_new_device+0x2a2/0x3c0 [<ffffffffa2a02ddc>] hub_thread+0xa3d/0xeed [<ffffffffa2c2010d>] ? __schedule+0x41e/0x5ac [<ffffffffa26957ce>] ? finish_wait+0x62/0x62 [<ffffffffa2a0239f>] ? usb_reset_device+0x16a/0x16a [<ffffffffa267b255>] kthread+0x108/0x110 [<ffffffffa267b14d>] ? __kthread_parkme+0x67/0x67 [<ffffffffa2c23b2c>] ret_from_fork+0x7c/0xb0 [<ffffffffa267b14d>] ? __kthread_parkme+0x67/0x67 Signed-off-by: Stephen Barber <smbarber@chromium.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-08-17 15:17:46 -07:00
ALSA: usb-audio: don't retry snd_usb_ctl_msg after timeout A few calls to snd_usb_ctl_msg wrap the function in a retry loop. In the worst case, the timeout for snd_usb_ctl_msg is 5 seconds, which when retried 10 times (for example, if a device is removed) could cause a probe to hang for ~50 seconds. Example stack trace from 3.14 which triggered a hung task timeout: Call Trace: [<ffffffffa2c1f720>] ? inet6_set_link_af.part.35+0x12/0x12 [<ffffffffa2c20309>] schedule+0x6e/0x70 [<ffffffffa2c1f81c>] schedule_timeout+0xfc/0x13c [<ffffffffa2667bbc>] ? rcu_read_unlock_sched_notrace+0x17/0x17 [<ffffffffa2c20d68>] __wait_for_common+0x153/0x190 [<ffffffffa2c20d68>] ? __wait_for_common+0x153/0x190 [<ffffffffa26890e5>] ? wake_up_state+0x12/0x12 [<ffffffffa2c20e0e>] wait_for_completion_timeout+0x1d/0x1f [<ffffffffa2a07c70>] usb_start_wait_urb+0x93/0xf1 [<ffffffffa2a07daf>] usb_control_msg+0xe1/0x11d [<ffffffffc02cd254>] snd_usb_ctl_msg+0x9c/0xf1 [snd_usb_audio] [<ffffffffc02ce191>] snd_usb_mixer_set_ctl_value+0x124/0xab1 [snd_usb_audio] [<ffffffffc02ce230>] snd_usb_mixer_set_ctl_value+0x1c3/0xab1 [snd_usb_audio] [<ffffffffc02ce58e>] snd_usb_mixer_set_ctl_value+0x521/0xab1 [snd_usb_audio] [<ffffffffc02cee88>] snd_usb_mixer_add_control+0x36a/0x1264 [snd_usb_audio] [<ffffffffc02cf323>] snd_usb_mixer_add_control+0x805/0x1264 [snd_usb_audio] [<ffffffffa2a06e11>] ? usb_free_urb+0x1a/0x1c [<ffffffffc02cfcf7>] snd_usb_mixer_add_control+0x11d9/0x1264 [snd_usb_audio] [<ffffffffc02d000f>] snd_usb_create_mixer+0xbc/0x286 [snd_usb_audio] [<ffffffffc02cac18>] 0xffffffffc02cac17 [<ffffffffa2a0aaf1>] usb_probe_interface+0x17c/0x21c [<ffffffffa29a65bc>] driver_probe_device+0xae/0x1fa [<ffffffffa29a6767>] __device_attach_driver+0x5f/0x66 [<ffffffffa29a6708>] ? driver_probe_device+0x1fa/0x1fa [<ffffffffa29a4a60>] bus_for_each_drv+0x87/0xaa [<ffffffffa29a688a>] __device_attach+0x9d/0x101 [<ffffffffa29a6913>] device_initial_probe+0x13/0x15 [<ffffffffa29a5ae6>] bus_probe_device+0x33/0x96 [<ffffffffa29a3d19>] device_add+0x328/0x547 [<ffffffffa2a09355>] usb_set_configuration+0x624/0x674 [<ffffffffa2a11949>] generic_probe+0x45/0x77 [<ffffffffa2a0a962>] usb_probe_device+0x2d/0x40 [<ffffffffa29a65bc>] driver_probe_device+0xae/0x1fa [<ffffffffa29a6767>] __device_attach_driver+0x5f/0x66 [<ffffffffa29a6708>] ? driver_probe_device+0x1fa/0x1fa [<ffffffffa29a4a60>] bus_for_each_drv+0x87/0xaa [<ffffffffa29a688a>] __device_attach+0x9d/0x101 [<ffffffffa29a6913>] device_initial_probe+0x13/0x15 [<ffffffffa29a5ae6>] bus_probe_device+0x33/0x96 [<ffffffffa29a3d19>] device_add+0x328/0x547 [<ffffffffa29030bc>] ? add_device_randomness+0x111/0x130 [<ffffffffa2a00967>] usb_new_device+0x2a2/0x3c0 [<ffffffffa2a02ddc>] hub_thread+0xa3d/0xeed [<ffffffffa2c2010d>] ? __schedule+0x41e/0x5ac [<ffffffffa26957ce>] ? finish_wait+0x62/0x62 [<ffffffffa2a0239f>] ? usb_reset_device+0x16a/0x16a [<ffffffffa267b255>] kthread+0x108/0x110 [<ffffffffa267b14d>] ? __kthread_parkme+0x67/0x67 [<ffffffffa2c23b2c>] ret_from_fork+0x7c/0xb0 [<ffffffffa267b14d>] ? __kthread_parkme+0x67/0x67 Signed-off-by: Stephen Barber <smbarber@chromium.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-08-17 15:17:46 -07:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Avoid nested autoresume calls After the recent fix of runtime PM for USB-audio driver, we got a lockdep warning like: ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc8+ #61 Not tainted --------------------------------------------- pulseaudio/980 is trying to acquire lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] but task is already holding lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] This comes from snd_usb_autoresume() invoking down_read() and it's used in a nested way. Although it's basically safe, per se (as these are read locks), it's better to reduce such spurious warnings. The read lock is needed to guarantee the execution of "shutdown" (cleanup at disconnection) task after all concurrent tasks are finished. This can be implemented in another better way. Also, the current check of chip->in_pm isn't good enough for protecting the racy execution of multiple auto-resumes. This patch rewrites the logic of snd_usb_autoresume() & co; namely, - The recursive call of autopm is avoided by the new refcount, chip->active. The chip->in_pm flag is removed accordingly. - Instead of rwsem, another refcount, chip->usage_count, is introduced for tracking the period to delay the shutdown procedure. At the last clear of this refcount, wake_up() to the shutdown waiter is called. - The shutdown flag is replaced with shutdown atomic count; this is for reducing the lock. - Two new helpers are introduced to simplify the management of these refcounts; snd_usb_lock_shutdown() increases the usage_count, checks the shutdown state, and does autoresume. snd_usb_unlock_shutdown() does the opposite. Most of mixer and other codes just need this, and simply returns an error if it receives an error from lock. Fixes: 9003ebb13f61 ('ALSA: usb-audio: Fix runtime PM unbalance') Reported-and-tested-by: Alexnader Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-08-25 16:09:00 +02:00
ALSA: usb-audio: Avoid nested autoresume calls After the recent fix of runtime PM for USB-audio driver, we got a lockdep warning like: ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc8+ #61 Not tainted --------------------------------------------- pulseaudio/980 is trying to acquire lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] but task is already holding lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] This comes from snd_usb_autoresume() invoking down_read() and it's used in a nested way. Although it's basically safe, per se (as these are read locks), it's better to reduce such spurious warnings. The read lock is needed to guarantee the execution of "shutdown" (cleanup at disconnection) task after all concurrent tasks are finished. This can be implemented in another better way. Also, the current check of chip->in_pm isn't good enough for protecting the racy execution of multiple auto-resumes. This patch rewrites the logic of snd_usb_autoresume() & co; namely, - The recursive call of autopm is avoided by the new refcount, chip->active. The chip->in_pm flag is removed accordingly. - Instead of rwsem, another refcount, chip->usage_count, is introduced for tracking the period to delay the shutdown procedure. At the last clear of this refcount, wake_up() to the shutdown waiter is called. - The shutdown flag is replaced with shutdown atomic count; this is for reducing the lock. - Two new helpers are introduced to simplify the management of these refcounts; snd_usb_lock_shutdown() increases the usage_count, checks the shutdown state, and does autoresume. snd_usb_unlock_shutdown() does the opposite. Most of mixer and other codes just need this, and simply returns an error if it receives an error from lock. Fixes: 9003ebb13f61 ('ALSA: usb-audio: Fix runtime PM unbalance') Reported-and-tested-by: Alexnader Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-08-25 16:09:00 +02:00
ALSA: usb-audio: don't retry snd_usb_ctl_msg after timeout A few calls to snd_usb_ctl_msg wrap the function in a retry loop. In the worst case, the timeout for snd_usb_ctl_msg is 5 seconds, which when retried 10 times (for example, if a device is removed) could cause a probe to hang for ~50 seconds. Example stack trace from 3.14 which triggered a hung task timeout: Call Trace: [<ffffffffa2c1f720>] ? inet6_set_link_af.part.35+0x12/0x12 [<ffffffffa2c20309>] schedule+0x6e/0x70 [<ffffffffa2c1f81c>] schedule_timeout+0xfc/0x13c [<ffffffffa2667bbc>] ? rcu_read_unlock_sched_notrace+0x17/0x17 [<ffffffffa2c20d68>] __wait_for_common+0x153/0x190 [<ffffffffa2c20d68>] ? __wait_for_common+0x153/0x190 [<ffffffffa26890e5>] ? wake_up_state+0x12/0x12 [<ffffffffa2c20e0e>] wait_for_completion_timeout+0x1d/0x1f [<ffffffffa2a07c70>] usb_start_wait_urb+0x93/0xf1 [<ffffffffa2a07daf>] usb_control_msg+0xe1/0x11d [<ffffffffc02cd254>] snd_usb_ctl_msg+0x9c/0xf1 [snd_usb_audio] [<ffffffffc02ce191>] snd_usb_mixer_set_ctl_value+0x124/0xab1 [snd_usb_audio] [<ffffffffc02ce230>] snd_usb_mixer_set_ctl_value+0x1c3/0xab1 [snd_usb_audio] [<ffffffffc02ce58e>] snd_usb_mixer_set_ctl_value+0x521/0xab1 [snd_usb_audio] [<ffffffffc02cee88>] snd_usb_mixer_add_control+0x36a/0x1264 [snd_usb_audio] [<ffffffffc02cf323>] snd_usb_mixer_add_control+0x805/0x1264 [snd_usb_audio] [<ffffffffa2a06e11>] ? usb_free_urb+0x1a/0x1c [<ffffffffc02cfcf7>] snd_usb_mixer_add_control+0x11d9/0x1264 [snd_usb_audio] [<ffffffffc02d000f>] snd_usb_create_mixer+0xbc/0x286 [snd_usb_audio] [<ffffffffc02cac18>] 0xffffffffc02cac17 [<ffffffffa2a0aaf1>] usb_probe_interface+0x17c/0x21c [<ffffffffa29a65bc>] driver_probe_device+0xae/0x1fa [<ffffffffa29a6767>] __device_attach_driver+0x5f/0x66 [<ffffffffa29a6708>] ? driver_probe_device+0x1fa/0x1fa [<ffffffffa29a4a60>] bus_for_each_drv+0x87/0xaa [<ffffffffa29a688a>] __device_attach+0x9d/0x101 [<ffffffffa29a6913>] device_initial_probe+0x13/0x15 [<ffffffffa29a5ae6>] bus_probe_device+0x33/0x96 [<ffffffffa29a3d19>] device_add+0x328/0x547 [<ffffffffa2a09355>] usb_set_configuration+0x624/0x674 [<ffffffffa2a11949>] generic_probe+0x45/0x77 [<ffffffffa2a0a962>] usb_probe_device+0x2d/0x40 [<ffffffffa29a65bc>] driver_probe_device+0xae/0x1fa [<ffffffffa29a6767>] __device_attach_driver+0x5f/0x66 [<ffffffffa29a6708>] ? driver_probe_device+0x1fa/0x1fa [<ffffffffa29a4a60>] bus_for_each_drv+0x87/0xaa [<ffffffffa29a688a>] __device_attach+0x9d/0x101 [<ffffffffa29a6913>] device_initial_probe+0x13/0x15 [<ffffffffa29a5ae6>] bus_probe_device+0x33/0x96 [<ffffffffa29a3d19>] device_add+0x328/0x547 [<ffffffffa29030bc>] ? add_device_randomness+0x111/0x130 [<ffffffffa2a00967>] usb_new_device+0x2a2/0x3c0 [<ffffffffa2a02ddc>] hub_thread+0xa3d/0xeed [<ffffffffa2c2010d>] ? __schedule+0x41e/0x5ac [<ffffffffa26957ce>] ? finish_wait+0x62/0x62 [<ffffffffa2a0239f>] ? usb_reset_device+0x16a/0x16a [<ffffffffa267b255>] kthread+0x108/0x110 [<ffffffffa267b14d>] ? __kthread_parkme+0x67/0x67 [<ffffffffa2c23b2c>] ret_from_fork+0x7c/0xb0 [<ffffffffa267b14d>] ? __kthread_parkme+0x67/0x67 Signed-off-by: Stephen Barber <smbarber@chromium.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-08-17 15:17:46 -07:00
ALSA: usb-audio: Support multiple control interfaces Registering Numark Party Mix II fails with error 'bogus bTerminalLink 1'. The problem stems from the driver not being able to find input/output terminals required to configure audio streaming. The information about those terminals is stored in AudioControl Interface. Numark device contains 2 AudioControl Interfaces and the driver checks only one of them. According to the USB standard, a device can have multiple audio functions, each represented by Audio Interface Collection. Every audio function is considered to be closed box and will contain unique AudioControl Interface and zero or more AudioStreaming and MIDIStreaming Interfaces. The Numark device adheres to the standard and defines two audio functions: - MIDIStreaming function - AudioStreaming function It starts with MIDI function, followed by the audio function. The driver saves the first AudioControl Interface in `snd_usb_audio` structure associated with the entire device. It then attempts to use this interface to query for terminals and clocks. However, this fails because the correct information is stored in the second AudioControl Interface, defined in the second Audio Interface Collection. This patch introduces a structure holding association between each MIDI/Audio Interface and its corresponding AudioControl Interface, instead of relying on AudioControl Interface defined for the entire device. This structure is populated during usb probing phase and leveraged later when querying for terminals and when sending USB requests. Alternative solutions considered include: - defining a quirk for Numark where the order of interface is manually changed, or terminals are hardcoded in the driver. This solution would have fixed only this model, though it seems that device is USB compliant, and it also seems that other devices from this company may be affected. What's more, it looks like products from other manufacturers have similar problems, i.e. Rane One DJ console - keeping a list of all AudioControl Interfaces and querying all of them to find required information. That would have solved my problem and have low probability of breaking other devices, as we would always start with the same logic of querying first AudioControl Interface. This solution would not have followed the standard though. This patch preserves the `snd_usb_audio.ctrl_intf` variable, which holds the first AudioControl Interface, and uses it as a fallback when some interfaces are not parsed correctly and lack an associated AudioControl Interface, i.e., when configured via quirks. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217865 Signed-off-by: Karol Kosik <k.kosik@outlook.com> Link: https://patch.msgid.link/AS8P190MB1285893F4735C8B32AD3886BEC852@AS8P190MB1285.EURP190.PROD.OUTLOOK.COM Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-11 17:29:56 -07:00
ALSA: usb-audio: Fix UAC2/3 effect unit parsing We've got a regression report about M-Audio Fast Track C400 device, and the git bisection resulted in the commit e0ccdef92653 ("ALSA: usb-audio: Clean up check_input_term()"). This commit was about the rewrite of the input terminal parser, and it's not too obvious from the change what really broke. The answer is: it's the interpretation of UAC2/3 effect units. In the original code, UAC2 effect unit is as if through UAC1 processing unit because both UAC1 PU and UAC2/3 EU share the same number (0x07). The old code went through a complex switch-case fallthrough, finally bailing out in the middle: if (protocol == UAC_VERSION_2 && hdr[2] == UAC2_EFFECT_UNIT) { /* UAC2/UAC1 unit IDs overlap here in an * uncompatible way. Ignore this unit for now. */ return 0; } ... and this special handling was missing in the new code; the new code treats UAC2/3 effect unit as if it were equivalent with the processing unit. Actually, the old code was too confusing. The effect unit has an incompatible unit description with the processing unit, so we shouldn't have dealt with EU in the same way. This patch addresses the regression by changing the effect unit handling to the own parser function. The own parser function makes the clear distinct with PU, so it improves the readability, too. The EU parser just sets the type and the id like the old kernels. Once when the proper effect unit support is added, we can revisit this parser function, but for now, let's keep this simple setup as is. Fixes: e0ccdef92653 ("ALSA: usb-audio: Clean up check_input_term()") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206147 Link: https://lore.kernel.org/r/20200211160521.31990-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-02-11 17:05:21 +01:00
ALSA: usb-audio: Fix UAC2/3 effect unit parsing We've got a regression report about M-Audio Fast Track C400 device, and the git bisection resulted in the commit e0ccdef92653 ("ALSA: usb-audio: Clean up check_input_term()"). This commit was about the rewrite of the input terminal parser, and it's not too obvious from the change what really broke. The answer is: it's the interpretation of UAC2/3 effect units. In the original code, UAC2 effect unit is as if through UAC1 processing unit because both UAC1 PU and UAC2/3 EU share the same number (0x07). The old code went through a complex switch-case fallthrough, finally bailing out in the middle: if (protocol == UAC_VERSION_2 && hdr[2] == UAC2_EFFECT_UNIT) { /* UAC2/UAC1 unit IDs overlap here in an * uncompatible way. Ignore this unit for now. */ return 0; } ... and this special handling was missing in the new code; the new code treats UAC2/3 effect unit as if it were equivalent with the processing unit. Actually, the old code was too confusing. The effect unit has an incompatible unit description with the processing unit, so we shouldn't have dealt with EU in the same way. This patch addresses the regression by changing the effect unit handling to the own parser function. The own parser function makes the clear distinct with PU, so it improves the readability, too. The EU parser just sets the type and the id like the old kernels. Once when the proper effect unit support is added, we can revisit this parser function, but for now, let's keep this simple setup as is. Fixes: e0ccdef92653 ("ALSA: usb-audio: Clean up check_input_term()") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206147 Link: https://lore.kernel.org/r/20200211160521.31990-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-02-11 17:05:21 +01:00
ALSA: usb-audio: Fix UAC2/3 effect unit parsing We've got a regression report about M-Audio Fast Track C400 device, and the git bisection resulted in the commit e0ccdef92653 ("ALSA: usb-audio: Clean up check_input_term()"). This commit was about the rewrite of the input terminal parser, and it's not too obvious from the change what really broke. The answer is: it's the interpretation of UAC2/3 effect units. In the original code, UAC2 effect unit is as if through UAC1 processing unit because both UAC1 PU and UAC2/3 EU share the same number (0x07). The old code went through a complex switch-case fallthrough, finally bailing out in the middle: if (protocol == UAC_VERSION_2 && hdr[2] == UAC2_EFFECT_UNIT) { /* UAC2/UAC1 unit IDs overlap here in an * uncompatible way. Ignore this unit for now. */ return 0; } ... and this special handling was missing in the new code; the new code treats UAC2/3 effect unit as if it were equivalent with the processing unit. Actually, the old code was too confusing. The effect unit has an incompatible unit description with the processing unit, so we shouldn't have dealt with EU in the same way. This patch addresses the regression by changing the effect unit handling to the own parser function. The own parser function makes the clear distinct with PU, so it improves the readability, too. The EU parser just sets the type and the id like the old kernels. Once when the proper effect unit support is added, we can revisit this parser function, but for now, let's keep this simple setup as is. Fixes: e0ccdef92653 ("ALSA: usb-audio: Clean up check_input_term()") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206147 Link: https://lore.kernel.org/r/20200211160521.31990-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-02-11 17:05:21 +01:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Kill stray URB at exiting USB-audio driver may leave a stray URB for the mixer interrupt when it exits by some error during probe. This leads to a use-after-free error as spotted by syzkaller like: ================================================================== BUG: KASAN: use-after-free in snd_usb_mixer_interrupt+0x604/0x6f0 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 kasan_report+0x23d/0x350 mm/kasan/report.c:409 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430 snd_usb_mixer_interrupt+0x604/0x6f0 sound/usb/mixer.c:2490 __usb_hcd_giveback_urb+0x2e0/0x650 drivers/usb/core/hcd.c:1779 .... Allocated by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772 kmalloc ./include/linux/slab.h:493 kzalloc ./include/linux/slab.h:666 snd_usb_create_mixer+0x145/0x1010 sound/usb/mixer.c:2540 create_standard_mixer_quirk+0x58/0x80 sound/usb/quirks.c:516 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 create_composite_quirk+0x1c4/0x3e0 sound/usb/quirks.c:59 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 usb_audio_probe+0x1040/0x2c10 sound/usb/card.c:618 .... Freed by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524 slab_free_hook mm/slub.c:1390 slab_free_freelist_hook mm/slub.c:1412 slab_free mm/slub.c:2988 kfree+0xf6/0x2f0 mm/slub.c:3919 snd_usb_mixer_free+0x11a/0x160 sound/usb/mixer.c:2244 snd_usb_mixer_dev_free+0x36/0x50 sound/usb/mixer.c:2250 __snd_device_free+0x1ff/0x380 sound/core/device.c:91 snd_device_free_all+0x8f/0xe0 sound/core/device.c:244 snd_card_do_free sound/core/init.c:461 release_card_device+0x47/0x170 sound/core/init.c:181 device_release+0x13f/0x210 drivers/base/core.c:814 .... Actually such a URB is killed properly at disconnection when the device gets probed successfully, and what we need is to apply it for the error-path, too. In this patch, we apply snd_usb_mixer_disconnect() at releasing. Also introduce a new flag, disconnected, to struct usb_mixer_interface for not performing the disconnection procedure twice. Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-10-10 14:10:32 +02:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to identify devices with sticky mixers. Unfortunately, even though most devices with sticky GET_CUR also have corresponding sticky SET_CUR, which I actually met more since the commit had been merged, there is also a rare case that some devices may have volume mixers that responds to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky check to consider the mixer to be sticky and unnecessarily disable it. As the sticky check can't distinguish between sticky mixers and working SET_CUR but broken GET_CUR, add QUIRK_FLAG_MIXER_GET_CUR_BROKEN to tell that the device should fall into the second category when GET_CUR returns a constant value. In this case, the sticky check becomes non-fatal and only disables GET_CUR instead of the whole mixer. The current volume will then be provided by the internal cache that stores the last set volume. An info message prompting users to check MIXER_GET_CUR_BROKEN for potential sticky mixers is also added, so that users can learn how to do some experiments to determine what's going on. If the mixer surprisingly turns out to be non-sticky, they can submit a patch for a new quirk table entry. Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260531-uac-quirk-get-cur-vol-v4-1-ede643dca151@rong.moe
2026-05-31 23:45:20 +08:00
ALSA: usb-audio: Kill stray URB at exiting USB-audio driver may leave a stray URB for the mixer interrupt when it exits by some error during probe. This leads to a use-after-free error as spotted by syzkaller like: ================================================================== BUG: KASAN: use-after-free in snd_usb_mixer_interrupt+0x604/0x6f0 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 kasan_report+0x23d/0x350 mm/kasan/report.c:409 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430 snd_usb_mixer_interrupt+0x604/0x6f0 sound/usb/mixer.c:2490 __usb_hcd_giveback_urb+0x2e0/0x650 drivers/usb/core/hcd.c:1779 .... Allocated by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772 kmalloc ./include/linux/slab.h:493 kzalloc ./include/linux/slab.h:666 snd_usb_create_mixer+0x145/0x1010 sound/usb/mixer.c:2540 create_standard_mixer_quirk+0x58/0x80 sound/usb/quirks.c:516 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 create_composite_quirk+0x1c4/0x3e0 sound/usb/quirks.c:59 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 usb_audio_probe+0x1040/0x2c10 sound/usb/card.c:618 .... Freed by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524 slab_free_hook mm/slub.c:1390 slab_free_freelist_hook mm/slub.c:1412 slab_free mm/slub.c:2988 kfree+0xf6/0x2f0 mm/slub.c:3919 snd_usb_mixer_free+0x11a/0x160 sound/usb/mixer.c:2244 snd_usb_mixer_dev_free+0x36/0x50 sound/usb/mixer.c:2250 __snd_device_free+0x1ff/0x380 sound/core/device.c:91 snd_device_free_all+0x8f/0xe0 sound/core/device.c:244 snd_card_do_free sound/core/init.c:461 release_card_device+0x47/0x170 sound/core/init.c:181 device_release+0x13f/0x210 drivers/base/core.c:814 .... Actually such a URB is killed properly at disconnection when the device gets probed successfully, and what we need is to apply it for the error-path, too. In this patch, we apply snd_usb_mixer_disconnect() at releasing. Also introduce a new flag, disconnected, to struct usb_mixer_interface for not performing the disconnection procedure twice. Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-10-10 14:10:32 +02:00
ALSA: usb-audio: Kill stray URB at exiting USB-audio driver may leave a stray URB for the mixer interrupt when it exits by some error during probe. This leads to a use-after-free error as spotted by syzkaller like: ================================================================== BUG: KASAN: use-after-free in snd_usb_mixer_interrupt+0x604/0x6f0 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 kasan_report+0x23d/0x350 mm/kasan/report.c:409 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430 snd_usb_mixer_interrupt+0x604/0x6f0 sound/usb/mixer.c:2490 __usb_hcd_giveback_urb+0x2e0/0x650 drivers/usb/core/hcd.c:1779 .... Allocated by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772 kmalloc ./include/linux/slab.h:493 kzalloc ./include/linux/slab.h:666 snd_usb_create_mixer+0x145/0x1010 sound/usb/mixer.c:2540 create_standard_mixer_quirk+0x58/0x80 sound/usb/quirks.c:516 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 create_composite_quirk+0x1c4/0x3e0 sound/usb/quirks.c:59 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 usb_audio_probe+0x1040/0x2c10 sound/usb/card.c:618 .... Freed by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524 slab_free_hook mm/slub.c:1390 slab_free_freelist_hook mm/slub.c:1412 slab_free mm/slub.c:2988 kfree+0xf6/0x2f0 mm/slub.c:3919 snd_usb_mixer_free+0x11a/0x160 sound/usb/mixer.c:2244 snd_usb_mixer_dev_free+0x36/0x50 sound/usb/mixer.c:2250 __snd_device_free+0x1ff/0x380 sound/core/device.c:91 snd_device_free_all+0x8f/0xe0 sound/core/device.c:244 snd_card_do_free sound/core/init.c:461 release_card_device+0x47/0x170 sound/core/init.c:181 device_release+0x13f/0x210 drivers/base/core.c:814 .... Actually such a URB is killed properly at disconnection when the device gets probed successfully, and what we need is to apply it for the error-path, too. In this patch, we apply snd_usb_mixer_disconnect() at releasing. Also introduce a new flag, disconnected, to struct usb_mixer_interface for not performing the disconnection procedure twice. Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-10-10 14:10:32 +02:00