| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
|
USB-audio driver keeps the bitmap for the cached mixer channels, but
since a 32bit integer is used, it's currently broken for over 32
channels. As the driver is supposed to support up to 64 channels,
this patch extends the bitmap properly -- now to be more flexible, use
the standard bitmap instead of the manual bit shifts.
Some checks for master channels are replaced in a slightly different
manner (checking the channel index 0) instead of the full cval->cached
check, so that it fits better in the bitmap helper usage.
Fixes: 16ee07bfa935 ("ALSA: usb-audio: Extend max number of channels to 64")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20261007172051.13240-8-tiwai@suse.de
|
|
The info callback for USB-audio mixer controls for feature unit has a
dynamic initialization of the contents with the check of
cval->initialized flag. But, since the info callback may be
concurrently called, this may lead to a data race, giving back an
inconsistent state. Similarly, get and put callbacks may have
concurrent accesses and can get bogus states.
For avoiding the data race, introduce a mutex locking for the
controls and protect against concurrent info callback calls.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20261007172051.13240-6-tiwai@suse.de
|
|
The bitmap matrix in the mixer unit descriptor for UAC2 and UAC3 has
rather the size of input-pins x output-pins, while the current
USB-audio driver code wrongly assumes the UAC1 bitmap matrix size,
which is input-channels x output-pins. That is, when input pins have
multiple channels, the column size differs and it leads to the
accesses at a wrong position.
This patch corrects the access of the bitmap matrix for UAC2/UAC3.
For making the code cleaner, split the parser to UAC1 and UAC2/3, too.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20261007172051.13240-5-tiwai@suse.de
|
|
The recent fix to avoid OOB access for malformed packets added a
packet length check and returns immediately if it's too short.
However, this can be lead to a regression because the completion
handler doesn't resubmit the packet, while a zero-length packet itself
is valid, per se.
For addressing the potential regression above, change the handling for
a zero-length packet to just resubmit without processing the incoming
contents.
Fixes: aba30af07d4f ("ALSA: usb-audio: caiaq: validate EP1 reply lengths")
Link: https://patch.msgid.link/20261006134405.479603-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Shanling UP4 (0a12:1244, CSR-based, UAC1, full speed) sets the
MaxPacketsOnly bit in its AS isochronous endpoint descriptor. With
UAC_EP_CS_ATTR_FILL_MAX set, the driver fills every 1 ms packet up to
wMaxPacketSize, i.e. 48 frames, regardless of the sample rate. At
44.1 kHz the device expects 44/45 frames per packet and outputs only
silence. 48 kHz works because both packet sizes are the same there.
Measured with aplay on hw:UP4,0, 4 s of S16_LE stereo:
before: 44.1 kHz consumed at ~48030 frames/s, done in 3.68 s, silent
after: 44.1 kHz consumed at ~44220 frames/s, done in 4.00 s, audible
48 kHz plays fine both before and after the change. Regular music
playback at 44.1 kHz through PipeWire sounds fine as well.
Clear the attribute for this device, as is already done for the MOTU
MicroBook IIc. Since the packet sizes are equal at 48 kHz, this does
not change anything for other devices that may share this CSR USB ID
and only use 48 kHz.
Link: https://lore.kernel.org/all/CAPHAwzdUNRbZjBQuYKLf18EK_QGq0gR6Vx3YMZ=ffYKBogUtLA@mail.gmail.com/
Signed-off-by: Vadym Shevchuk <0xsheff@gmail.com>
Link: https://patch.msgid.link/20261005125953.190316-1-0xsheff@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Yamaha 01V96i exposes its audio streaming interfaces as
vendor-specific USB class 0xff and ships no class-specific endpoint
descriptor. parse_uac_endpoint_attributes() therefore returns no
attributes for the device, and without UAC_EP_CS_ATTR_SAMPLE_RATE the
driver never issues the SET_CUR sampling-frequency request the hardware
needs to start its USB audio stream. The playback and capture PCMs are
reported as RUNNING and their pointers advance, but the mixer passes no
audio in either direction.
The vendor (Yamaha Steinberg) driver on Windows sends this request at
startup; the generic driver does not. Add the 01V96i to
snd_usb_audioformat_attributes_quirk() to force the attribute on, so the
stream is initialised the same way.
Confirmed against a usbmon capture of the Windows vendor driver: SET_CUR
CS_SAMPLING_FREQ_CONTROL to endpoints 0x07 and 0x86 is the only
non-standard control transfer it issues that completes successfully.
Verified on a mainline 7.2.9 kernel with a loopback test: playing a
440 Hz tone on USB channels 1/2 and recording USB channels 9/10 returns
the tone unchanged at 44100, 48000, 88200 and 96000 Hz.
Tested-by: Justin Bacle <justin.bacle@gmail.com>
Signed-off-by: Justin Bacle <justin.bacle@gmail.com>
Link: https://patch.msgid.link/20261004192102.59312-1-justin.bacle@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Cambridge Audio streamer advertises the UAC2 RAW_DATA format on
altsetting 2 of its playback interface, but without the DSD_RAW quirk
flag the driver exposes it only as a SPECIAL format that cannot be
used.
Add QUIRK_FLAG_DSD_RAW for the device (USB ID 22e8:ca10), so the
altsetting is exposed as DSD_U32_BE, enabling native DSD64/128/256
playback.
Tested with: gst-launch-1.0 filesrc location=file.dsf ! \
avdemux_dsf ! dsdconvert ! \
alsasink device=hw:2,0
Signed-off-by: Matus Gajdos <matuszpd@gmail.com>
Link: https://patch.msgid.link/20261002125237.82188-1-matuszpd@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
UAC2 feature and mixer units provide the mixer information about
minimum and max channels as well as the resolution in a single
UAC2_CS_RANGE request, but the current code tries to extract each of
them in an old way of UAC1.
This patch refactors the code to optimize the range info extraction
for UAC2. Now the code for obtaining min/max/res info is done in
get_ctl_range() function. For UAC1, this will call UAC_GET_MIN,
UAC_GET_MAX and UAC_GET_RES requests, while it calls a single
UAC2_CS_RANGE for UAC2/3.
Link: https://lore.kernel.org/d46fcac6-bd7e-4fc4-95e1-4e8d39f92ad3@zipdox.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260930155356.348608-4-tiwai@suse.de
|
|
For a request for a Mixer Unit on UAC2 (also UAC3), the wValue is
different from UAC1 and an incompatible value must be passed.
Namely, UAC1 takes a word consisting of 1-based input channel in the
high byte and 1-based output channel in the low byte.
Meanwhile, UAC2/3 takes UAC2_MU_MIXER in the high byte and a MCN
(0-based bit position of input/output channels) in the low byte.
The current driver implementation blindly assumes the UAC1 way, hence
it would cause a firmware error.
This patch attempts to implement the conversion to UAC2 MCN at
get_ctl_value_v2() and snd_usb_mixer_set_ctl_value() for mixer units.
At the points above, the old wValue containing ICN and OCN is
converted to the corresponding MCN, and it's used as the proper
wValue.
Reported-by: Zipdox <zipdox@zipdox.net>
Closes: https://lore.kernel.org/d46fcac6-bd7e-4fc4-95e1-4e8d39f92ad3@zipdox.net
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260930155356.348608-3-tiwai@suse.de
|
|
The matrix of input/output channels specified in a UAC2/3 mixer unit
must fit to the upper limit 256. Add a sanity check and returns an
error if an invalid size is detected.
Link: https://lore.kernel.org/d46fcac6-bd7e-4fc4-95e1-4e8d39f92ad3@zipdox.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260930155356.348608-2-tiwai@suse.de
|
|
Pull 7.3-devel branch again for further development of USB-audio stuff.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Faaris reported a problem with Audient EVO4 device and it turned out
to be a regression by the recent fix commit 87a6f2fa6e6c ("ALSA:
usb-audio: Propagate write errors in generic mixer put callbacks").
It exhibited that the hardware gives errors at accessing the mixer
unit 10 on certain channels, and the change above made it a fatal
error.
We had already a quirk for Audient iD14 to work around such errors
from the mixer controls, and we can simply apply the same for EVO4.
OTOH, it's highly possible that other Audient devices suffer from the
same issue; they must be using similar firmware, after all.
So, in this patch, we apply the quirk generically to all devices with
the vendor ID Audient (2708), instead. Ignoring the control error
isn't usually less critical than overreaction to the firmware
misbehavior.
Fixes: 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks")
Reported-and-tested-by: Faaris Ansari <faarisansari@googlemail.com>
Closes: https://lore.kernel.org/CANBVYRCL=8QdLxGg4S6qrahrFtwJxhv-aSGpW7-1S=+iOe4ZGA@mail.gmail.com
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260929144132.1521617-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Jan reported that a few Behringer devices became broken since the
recent optimization to avoid usb_string() call at probe time at the
commit b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev
for manufacturer & co"). Interestingly, the devices seem requiring
the explicit descriptor read at probing time, and the optimization
above dropped it.
There is already a boot quirk for another model, Behringer CM1A
(1397:1234), that adds a device descriptor read, and this seems
working for them, too. As the quirk is safe and cheap, just apply the
same boot quirk to all Behringer devices for avoiding the pitfall
again.
Fixes: b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev for manufacturer & co")
Reported-by: Jan Lentfer <jan.lentfer@web.de>
Closes: https://lore.kernel.org/e7087d42-5e74-4d85-b1c5-b11eff235d41@web.de
Link: https://patch.msgid.link/20260929122938.1471867-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The USB MIDI driver changes the Roland MIDI Input Mode control's access
flags directly from the rawmidi open and close paths. These changes are
not protected by the ALSA control core and the corresponding notifications
can race with control access.
Use snd_ctl_activate_id() so that the control core updates the access flags
and sends the notification under its lock. Release the USB MIDI mutex
before calling it because the control write path holds controls_rwsem while
roland_load_put() takes the USB MIDI mutex.
Keep the state transition and alternate-setting change under the USB MIDI
mutex; rawmidi's open mutex serializes the enclosing open and close paths.
Fixes: 96f61d9ade82 ("sound: usb-audio: allow switching altsetting on Roland USB MIDI devices")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://patch.msgid.link/20260929141726.2166899-1-runyu.xiao@seu.edu.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The controls enumerated by the Audient EVO4 are incomplete. Add missing
controls for
* channel muting
* the cross-fader
* the recording mixer
* phantom power
The driver is structured so that it should be trivial to extend it to the
EVO8 (and potentially other Audient devices) but we need a kind soul who
has access to that hardware to correctly map the control names and test
everything.
Signed-off-by: Christian Ruppert <arc@gmx.li>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260919151840.24371-3-arc@gmx.li
|
|
The Audient EVO4 master volume mixer channel enumerates as 'EVO4 '. Rename
it to 'Master' according to control-names.rst.
Signed-off-by: Christian Ruppert <arc@gmx.li>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260919151840.24371-2-arc@gmx.li
|
|
The NUX NAI-24 (USB 3703:2000) has a UAC2 clock source that reports
bmAttributes = 0x01 (internal fixed clock) and bmControls = 0x07, so the
driver treats its sample rate as programmable. When the driver sends
SET_CUR(SAMPLING_FREQ_CONTROL), the firmware acknowledges the request and
then runs the clock on the opposite base-rate family: asking for 44100 Hz
makes the device run at 48000 Hz, and asking for 48000 Hz makes it run at
44100 Hz.
The result is playback that is about 8.8% fast, or 8.4% slow with heavy
static on the 48000 Hz family. macOS and Windows ignore bmControls, treat
the clock as fixed and resample, so they are unaffected.
Work around it by sending the partner rate in SET_CUR for this device, so
the device runs at the requested rate. A new QUIRK_FLAG_SWAP_RATES flag
controls this, applied through the quirk flags table.
Only the 44.1/48 kHz pair has been verified on hardware; the 88.2/96 kHz
and 176.4/192 kHz pairs are untested but follow the same pattern.
Testing: the equivalent change ran on the device as a locally built
module (44100 Hz PCM, device clock 44100 Hz, no xruns, correct tempo, no
static). This upstream form compiles for sound/usb without warnings and
passes checkpatch, but has not been built in a full kernel tree or
load-tested.
Assisted-by: LLM
Signed-off-by: Darren Chang <darrenchangjr01@gmail.com>
Link: https://patch.msgid.link/20260920122653.41993-1-darrenchangjr01@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Xiaomi 2717:d005 USB audio transmitter supports Sound 2 Pro and
Sound 2 Max speakers. This issue was reproduced with two Sound 2 Pro
speakers paired in stereo. After a USB replug, Linux detects the
transmitter and exposes a hardware volume control, but moving the volume
slider changes neither the audible level nor the speakers' volume LEDs.
Windows controls the same speakers with its in-box USB Audio driver.
USB captures show standard UAC2 volume SET_CUR requests on both systems.
Re-reading the device descriptor (18 bytes), configuration header
(9 bytes), and full configuration descriptor (184 bytes on the tested
unit) after 2717:d005 is configured restores hardware volume control.
The USBFS sequence recovered the device after multiple replug tests.
Reading only the device descriptor did not restore volume control.
Perform these reads when snd-usb-audio first probes 2717:d005. Use the
configuration header's wTotalLength for the final read. If a read fails,
warn and continue probing so that playback remains available.
Tested on 7.2.6-zen2-1-zen with the existing userspace workaround
disabled. After a physical USB replug, the quirk ran when 2717:d005
appeared, and both audible volume and the speakers' LEDs followed the
KDE volume slider.
Signed-off-by: Xucheng Pan <panxucc@gmail.com>
Link: https://patch.msgid.link/20260923152552.943151-1-panxucc@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Both Kore controllers have a 128x64 pixel monochrome LCD. The driver
does not support it, and userspace cannot reach it while the driver is
bound, so the display stays blank on Linux.
The firmware passes EP1 packets with the command byte 0x08 on to an
ST7565-style display controller: "08 00 <n> <commands>" carries
controller commands, "08 01 <n> <data>" display RAM data. The vendor
software sets the controller up, then writes each 128 byte page in
blocks of 32 bytes, each preceded by page and column address commands.
The OpenKoreBridge project documented this from USB captures of the
vendor software with a Kore 2.
Add a hwdep device, "Kore LCD", for both controllers. A write carries
one frame of 1024 bytes: 8 pages of 128 columns, with bit 0 as the top
pixel of each page. The driver sets the controller up on the first
write and afterwards only sends the pages that changed. The device is
exclusive, so frames from different writers cannot interleave. Add an
"LCD Contrast" control (0-63); the backlight is already the "LED lcd"
control.
Tested on a Kore controller (USB ID 17cc:4711): full frames, frames that
change single pages and contrast changes show up as expected, while
audio, MIDI, input and the LEDs keep working. A Kore 2 was not available
for testing; it gets the protocol that OpenKoreBridge uses with it.
Link: https://github.com/OpenKoreBridge/OpenKoreBridge
Assisted-by: LLM
Signed-off-by: Niko Huuskonen <niko.huuskonen.00@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260927003532.289468-5-niko.huuskonen.00@gmail.com
|
|
keycode_kore does not match the hardware in two places:
- Softkeys 5 to 8 are listed in reverse order, so pressing the fifth
softkey reports BTN_8, the sixth BTN_7 and so on. Softkeys 1 to 4 are
correct. The OpenKoreBridge project, which drives a Kore 2 through
this driver, works around the same reversal in userspace.
- On the first Kore controller the touch sensors of the eight knobs are
scrambled: touching knob 1 reports KEY_BRL_DOT6, knob 2 KEY_BRL_DOT8,
knob 3 KEY_BRL_DOT2, knob 6 KEY_BRL_DOT7, knob 7 KEY_BRL_DOT1 and
knob 8 KEY_BRL_DOT3. Only knobs 4 and 5 are right.
Put the softkeys in order for both controllers, and give the first Kore
controller its own touch sensor order, so that BTN_n and KEY_BRL_DOTn
belong to the n-th knob. The touch sensor order of the Kore 2 is left
alone, as it could not be checked.
Userspace that compensates for the old order needs to follow. It can
read the key map with EVIOCGKEYCODE, which also makes it possible to
support kernels with and without this change.
Tested on a Kore controller (USB ID 17cc:4711).
Link: https://github.com/OpenKoreBridge/OpenKoreBridge
Fixes: 8e3cd08ed8e5 ("[ALSA] caiaq - add control API and more input features")
Assisted-by: LLM
Signed-off-by: Niko Huuskonen <niko.huuskonen.00@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260927003532.289468-3-niko.huuskonen.00@gmail.com
|
|
snd_usb_caiaq_send_command() and snd_usb_caiaq_send_command_bank() copy
the command into cdev->ep1_out_buf and send it with a synchronous bulk
transfer. Nothing serializes their callers. An ALSA control write, which
sets the LEDs on the Kore controllers and several other devices, can run
at the same time as a PCM prepare, which sends the audio parameters
through the same buffer. One caller can then overwrite the buffer while
the transfer of the other is still in flight, and the device receives a
mix of both commands.
Protect the buffer with a mutex. All callers run in process context and
already sleep in usb_bulk_msg().
The problem was found by code review while adding another user of the
buffer, the Kore LCD support later in this series. It has not been
observed or reproduced.
Fixes: 8e3cd08ed8e5 ("[ALSA] caiaq - add control API and more input features")
Assisted-by: LLM
Signed-off-by: Niko Huuskonen <niko.huuskonen.00@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260927003532.289468-2-niko.huuskonen.00@gmail.com
|
|
Pull 7.3 devel branch for applying the further HD-audio quirks more
cleanly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
setup_card() registers the input device, whose name and phys point into
struct snd_usb_caiaqdev, and then goes on to snd_card_register() and
snd_usb_caiaq_control_init(). If either fails, snd_probe() calls
snd_card_free(), which frees the device state but leaves the input
device registered: card_free() only clears the pointer, and the input
device is unregistered from snd_disconnect() alone. Reading its "uevent"
attribute afterwards dereferences freed memory:
BUG: KASAN: slab-use-after-free in string+0x4a9/0x4f0
Read of size 1 at addr ffff8880208f5043 by task caiaq/4967
add_uevent_var+0x183/0x3a0
input_dev_uevent+0x162/0x900
dev_uevent+0x2f1/0x870
uevent_show+0x1ca/0x3a0
...
Unregister the input device on the probe error path, as
snd_disconnect() does. snd_usb_caiaq_input_disconnect() is a no-op when
no input device was registered.
Reproduced with a raw-gadget Audio Kontrol 1 and a temporary hack that
makes snd_usb_caiaq_control_init() fail.
Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly")
Cc: stable@vger.kernel.org
Reported-by: syzbot+2a123f6269da57ffefaa@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=2a123f6269da57ffefaa
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Link: https://patch.msgid.link/20260925170717.22462-1-ngocthang2710.1999@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The USB audio device 0db0:cc78 (Realtek ALC4080) on the MSI MAG B850M
MORTAR WIFI motherboard exposes all playback controls as "PCM", which
makes it hard to tell the outputs apart.
Its mixer layout matches the one of the MSI MPG X570S Carbon Max Wifi
(units 29, 30 and 32), so reuse msi_mpg_x570s_carbon_max_wifi_alc4080_map
for this device too. With the mapping applied, the controls show up as
"Speaker", "Front Headphone" and "IEC958".
Tested with a patched snd-usb-audio module on a 7.2.7 kernel.
Signed-off-by: Tomasz Bojanowski <tomasz@bojanowski.me>
Link: https://patch.msgid.link/20260923184957.6687-1-tomasz@bojanowski.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The ASUS SupremeFX Hi-Fi (0b05:1826, 0b05:1827) does not survive USB
autosuspend. After a suspend/resume cycle the firmware degrades: HID
probes begin to fail and the descriptors it returns become corrupted,
until the device stops responding entirely and needs a physical power
cycle to recover.
Add QUIRK_FLAG_DISABLE_AUTOSUSPEND for both product IDs.
Verified on 7.2.6 through the quirk_flags module parameter, with no
code change, and with the local udev rules that had been forcing
power/control commented out, so the parameter was the only mechanism
in play. Both IDs were passed as
0b05:1827:disable_autosuspend;0b05:1826:disable_autosuspend
The device then stayed awake across 2.5 hours (runtime_suspended_time
remained 0), survived a system suspend/resume cycle, and continued to
work afterwards with no failed probes and no power cycle needed.
Signed-off-by: Roman Bolotov <hadros@ikeepitoblique.com>
Link: https://patch.msgid.link/20260923064527.434441-1-hadros@ikeepitoblique.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HiBy FC4 with USB ID 32bb:0004 advertises its native DSD
stream as UAC2 RAW_DATA with a 4-byte, 32-bit subslot. Without a
quirk snd-usb-audio leaves this alternate setting as
SNDRV_PCM_FORMAT_SPECIAL, so userspace cannot select a native DSD
format.
Mark the device with QUIRK_FLAG_DSD_RAW so the existing generic raw
DSD handling exposes the stream as DSD_U32_BE.
Tested on an FC4 at DSD256. With the quirk the playback alternate
setting changes from SPECIAL to DSD_U32_BE and reports DOP=0,
bitrev=0; native DSD256 playback works correctly.
Signed-off-by: Achilles Zhang <bnqzzdf@gmail.com>
Link: https://patch.msgid.link/20260921024344.391912-1-bnqzzdf@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Each playback URB is handed a slice of out.buffer that is exactly
LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT
endpoint, but the number of bytes written into that slice is never
compared against it.
submit_audio_out_urb() takes the frame count from prev_fsize, which
audio_in_callback() derived from the *IN* endpoint's received packet
length, and rescales it with the playback frame size; when prev_fsize is
still zero it synthesizes a length from the sample rate instead. On a
device declaring a large IN wMaxPacketSize and a small OUT
wMaxPacketSize, the resulting memcpy(), or the memset() when the
playback stream is idle, runs past its slice and, as the reproducer
below shows, beyond the allocation.
usb_submit_urb() is not a backstop. max_packet_size_out comes from
usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize,
while USB core validates a high-speed isochronous length against that
base scaled by usb_endpoint_maxp_mult(). A length of up to three times
the allocated slice is therefore accepted, and even a rejected URB is
only rejected after the write.
Reject a packet that does not fit the slice the driver allocated for it.
Clamping it instead would silently shorten the capture-derived rate
feedback and desynchronize the two streams.
BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229)
Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002
Workqueue: events line6_startup_work
Call Trace:
__asan_memcpy (mm/kasan/shadow.c:106)
submit_audio_out_urb (sound/usb/line6/playback.c:229)
line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291)
line6_stream_start (sound/usb/line6/pcm.c:194)
line6_pcm_acquire (sound/usb/line6/pcm.c:337)
line6_startup_work (sound/usb/line6/driver.c:728)
process_one_work (kernel/workqueue.c:3396)
worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
The buggy address belongs to the object at ffff888100bbd400
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes inside of
allocated 256-byte region [ffff888100bbd400, ffff888100bbd500)
Cc: stable@vger.kernel.org
Fixes: 7a0f55aeeb8f ("ALSA: line6: Support assymetrical in/out configurations")
Reported-by: <co+be8fa7ea6f77fdce@bugs.sh>
Assisted-by: LLM
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://patch.msgid.link/20260918234014.1318325-1-xmei5@asu.edu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
detect_usb_format() cross-checks bSubframeSize, bBitResolution and
tSamFreq between the capture and playback interfaces, but never relates
the two endpoints' wMaxPacketSize and bNrChannels. Each playback URB
gets a buffer of ua->playback.max_packet_bytes, while the number of
bytes written into it is derived from the capture stream:
capture_urb_complete() computes frames from the received capture packet
and capture.frame_bytes, and start_usb_playback() and playback_work()
multiply that by playback.frame_bytes.
A device declaring a large capture wMaxPacketSize with few capture
channels and a small playback wMaxPacketSize with many playback channels
therefore memset()s and memcpy()s past the end of the playback buffer,
in open() of the PCM node the driver registers during probe.
usb_submit_urb() rejects the over-long iso_frame_desc[0].length with
-EMSGSIZE, but only after the write.
Reject such descriptors at probe time. Genuine UA-101/UA-1000 hardware
declares proportional packet sizes and is unaffected.
BUG: KASAN: slab-out-of-bounds in start_usb_playback (sound/usb/misc/ua101.c:586)
Write of size 2048 at addr ffff8881098f3c00 by task exploit/5021
Call Trace:
__asan_memset (mm/kasan/shadow.c:84)
start_usb_playback (sound/usb/misc/ua101.c:586)
playback_pcm_open (sound/usb/misc/ua101.c:679)
snd_pcm_open_substream (sound/core/pcm_native.c:2829)
snd_pcm_open (sound/core/pcm_native.c:2865 sound/core/pcm_native.c:2932)
snd_pcm_playback_open (sound/core/pcm_native.c:2891)
snd_open (sound/core/sound.c:166)
chrdev_open (fs/char_dev.c:411)
do_dentry_open (fs/open.c:996)
vfs_open (fs/open.c:1101)
path_openat (fs/namei.c:4837 fs/namei.c:5000)
do_file_open (fs/namei.c:5029)
do_sys_openat2 (fs/open.c:1417)
__x64_sys_openat (fs/open.c:1423 fs/open.c:1439 fs/open.c:1434)
do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
The buggy address belongs to the object at ffff8881098f3c00
which belongs to the cache kmalloc-192 of size 192
The buggy address is located 0 bytes inside of
allocated 168-byte region [ffff8881098f3c00, ffff8881098f3ca8)
Cc: stable@vger.kernel.org
Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support")
Reported-by: <co+24304d323d28f156@bugs.sh>
Assisted-by: LLM
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://patch.msgid.link/20260918225753.1278505-1-xmei5@asu.edu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Convert open-coded if/else with set_bit/clear_bit and their
non-atomic __set_bit/__clear_bit variants to the assign_bit/__assign_bit
API.
Done with Coccinelle semantic patch:
// set_bit -> clear_bit => assign_bit
@@
expression cond, bit, addr;
@@
-if (cond)
- set_bit(bit, addr);
-else
- clear_bit(bit, addr);
+assign_bit(bit, addr, cond);
// clear_bit -> set_bit => assign_bit
@@
expression cond, bit, addr;
@@
-if (cond)
- clear_bit(bit, addr);
-else
- set_bit(bit, addr);
+assign_bit(bit, addr, !cond);
// __set_bit -> __clear_bit => __assign_bit
@@
expression cond, bit, addr;
@@
-if (cond)
- __set_bit(bit, addr);
-else
- __clear_bit(bit, addr);
+__assign_bit(bit, addr, cond);
// __clear_bit -> __set_bit => __assign_bit
@@
expression cond, bit, addr;
@@
-if (cond)
- __clear_bit(bit, addr);
-else
- __set_bit(bit, addr);
+__assign_bit(bit, addr, !cond);
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260918141532.3022761-1-peng.fan@oss.nxp.com
|
|
stop_urbs() clears ep->ready_playback_urbs with a bare INIT_LIST_HEAD()
instead of unlinking each queued snd_urb_ctx. If a URB survives past
wait_clear_urbs()'s forced STOPPING->STOPPED timeout, its ctx is left
looking "linked" (stale next/prev) even though the list head has
forgotten it. When the endpoint later restarts and re-queues that same
ctx onto the (now real) ready list, and the old URB's completion
handler then calls push_back_to_ready_list() for it a second time, the
ctx is still the list's own tail and list_add's double-add check trips:
kernel BUG at lib/list_debug.c:35 (list_add double add)
Guard push_back_to_ready_list() with a list_empty() check so a
still-linked ctx isn't re-added, and make stop_urbs() actually unlink
each ctx via list_del_init() instead of only resetting the head, so a
dropped ctx doesn't keep looking linked to that guard.
Reported-by: syzbot+9fe3b8d9f5c64ff410a7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9fe3b8d9f5c64ff410a7
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Link: https://patch.msgid.link/20260915163110.58124-1-ngocthang2710.1999@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Correct spelling mistakes in comments. No functional change.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260915084424.1007757-4-hemanth.selam@gmail.com
|
|
The TD-11 hands MIDI handling off to the host once connected via
USB. If no MIDI input port is opened on the host, the device itself
becomes unusable as a standalone instrument until its input is
serviced, independent of anything happening on the computer.
Add a per-device keep_input_running flag, set for the TD-11 in
snd_usbmidi_detect_roland(), and check it alongside the existing
opened[1] check in snd_usbmidi_input_start()/snd_usbmidi_input_stop()
so that input is started at device creation and never stopped for
these devices, regardless of whether a client has the input port
open.
Signed-off-by: Nicholas Hobson <nicholas.hobson@outlook.com>
Link: https://patch.msgid.link/MN2PR15MB3472557AF39DC3A4CA9E753FF8BD2@MN2PR15MB3472.namprd15.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Skip the nonfunctional master mute control on the AVerMedia Live Gamer
ULTRA S GC553Pro (07ca:1553).
USB tracing shows that GET_CUR returns zero bytes instead of the required
one-byte value, both through usbfs and during ALSA initialization.
SET_CUR succeeds, but switching capture off does not mute HDMI audio.
Before the change, the driver exposed a misleading PCM Capture Switch
and logged: 3:2: failed to get current value for ch 0 (-22)
With the patch applied, the switch and warning are absent. A ten-second
sound recording through PipeWire confirmed that stereo 48 kHz, 16-bit
capture still works.
Tested on NixOS with the patched 7.3.0-rc3 kernel. The USB audio driver
object builds with Clang and W=1; sparse and strict checkpatch pass.
Signed-off-by: Asai Neko <sugar@sne.moe>
Link: https://patch.msgid.link/20260914-avermedia-gc553pro-alsa-v1-1-4c694e8b0cd5@sne.moe
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
usb6fire_pcm_in_urb_handler() sizes each outgoing isochronous packet as
(actual_length - 4) / (in_n_analog << 2) * (out_n_analog << 2) + 4, where
actual_length is the unsigned length the device reported for the matching
IN packet. A packet completed with status 0 and actual_length < 4 wraps
the subtraction to 0x7fffffec; a zero-length isochronous packet is legal
on the bus, and the preceding loop rejects only non-zero status. The sum
reaches memset() on out_urb->buffer, a 4832-byte object from
kcalloc(PCM_MAX_PACKET_SIZE, PCM_N_PACKETS_PER_URB).
Even without the wrap the result is out of bounds: at 88.2/96 kHz the
4-in/6-out scaling turns a full 420-byte IN packet into 628, so eight
packets span 5024 bytes of that buffer. usb_submit_urb() rejects an
over-long descriptor only after the memset() and the
usb6fire_pcm_playback() copy of user PCM data have run.
Guard the subtraction as the sibling usb6fire_pcm_capture() already does,
and limit the frame count to what fits in rt->out_packet_size, the OUT
endpoint's wMaxPacketSize. This bounds total_length by the buffer size
while keeping each packet length aligned to a whole output frame.
BUG: KASAN: out-of-bounds in usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338)
Write of size 18446744073709551456 at addr ffff88802a3d0000 by task vhci_rx/5018
Call Trace:
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
kasan_report (mm/kasan/report.c:595)
kasan_check_range (mm/kasan/generic.c:186 mm/kasan/generic.c:200)
__asan_memset (mm/kasan/shadow.c:84)
usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338)
__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657)
usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741)
vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107 drivers/usb/usbip/vhci_rx.c:242)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Allocated by task 10:
__kmalloc_cache_noprof (mm/slub.c:5563)
usb6fire_pcm_init (sound/usb/6fire/pcm.c:560 sound/usb/6fire/pcm.c:595)
usb6fire_chip_probe (sound/usb/6fire/chip.c:133)
usb_probe_interface (drivers/usb/core/driver.c:399)
The buggy address belongs to the object at ffff88802a3d0000
which belongs to the cache kmalloc-8k of size 8192
The buggy address is located 0 bytes inside of
4832-byte region [ffff88802a3d0000, ffff88802a3d12e0)
Kernel panic - not syncing: Fatal exception in interrupt
Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB")
Reported-by: co+855929c2df672879@bugs.sh
Closes: https://lore.kernel.org/all/gisnub8aWGLbyZLcDCSc7zWsHonMWGcyRgt5%40bugs.sh/
Assisted-by: LLM
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://patch.msgid.link/20260914074324.3590843-1-xmei5@asu.edu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Behringer FCA1616 (1397:0004) returns silent capture samples unless its
playback endpoint is active.
Use the existing fixed implicit-feedback mechanism to keep playback endpoint
0x01 on interface 1 active during capture.
Tested with 16-channel S32_LE capture at 44.1 and 48 kHz.
Signed-off-by: Kitty Makin <autumnull@posteo.net>
Link: https://patch.msgid.link/20260914002334.12691-1-autumnull@posteo.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Pioneer DJ DDJ-SZ exposes its audio interface as USB vendor-specific
class (0xFF) rather than USB Audio Class, so it needs a quirks-table
entry like its sibling Pioneer devices (DJM-750, DJM-850, DJM-900NXS2,
DJM-450, DJM-V10) already have.
The device presents 10 channels of S24_3LE audio in both directions,
fixed at 44.1kHz, on interface 0 altsetting 1: playback on endpoint
0x01, capture on endpoint 0x82. The unit contains its own analog mixer,
and each playback channel pair feeds one of its physical channel strips:
0/1, 2/3, 4/5 and 6/7 feed strips 1-4 respectively, and 8/9 feed the
booth output. The master output is produced in analog by that mixer and
is not carried over USB at all. On the capture side, channels 8/9 are
the mic input; capture channels 0-7 are not yet mapped to specific
physical inputs.
Implicit feedback needs no quirk flag here: is_pioneer_implicit_fb() in
implicit.c already covers vendor 0x08e4 with a vendor-spec class
interface and two endpoints, and the driver duly reports endpoint 0x82
as the playback sync endpoint.
Activation reuses the existing pioneer_djm_set_format_quirk() used by
the DJM-750/850/900NXS2/450/V10 (SET_INTERFACE to altsetting 1, then a
UAC-shaped SET_CUR sample-rate control transfer) with this device's own
captured wIndex (0x0082). Unlike those devices, the DDJ-SZ additionally
needs a vendor "arm" sequence before its capture path produces real
audio -- without it, capture opens and runs with no USB/ALSA errors
but delivers silence (a hard zero on every channel) rather than any
error, so this is easy to miss. The arm sequence is six vendor control
transfers (bmRequestType=0x40, bRequest=3, varying wValue/wIndex, each
followed by a bmRequestType=0xc0, bRequest=0 status read), replicated
byte-for-byte from a USB capture of the official Windows driver.
All of the above -- endpoint numbers, format, channel mapping, and the
arm sequence bytes -- were determined by capturing and decoding real USB
traffic from the Windows driver (USBPcap + Wireshark) during
enumeration, playback, and mic recording, then verifying the format
hypothesis against actual de-interleaved payload data rather than
packet-size arithmetic alone. Both playback and capture have been
verified working with real audio, not just clean enumeration.
Signed-off-by: Hanh Kieu <hhkieu@gmail.com>
Link: https://patch.msgid.link/20260903231641.18536-1-hhkieu@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
data_ep_set_params() allocates each data URB for exactly u->packets
isochronous frames, so urb->iso_frame_desc[] has u->packets slots and
ctx->packets is the driver's only record of that limit. For an implicit
feedback sink, snd_usb_queue_pending_output_urbs() overwrites it with the
sync source's packet count, which is calculated independently from the
capture endpoint's parameters. When that count is larger,
prepare_playback_urb() and prepare_silent_urb() can write
iso_frame_desc[] past the allocation; their existing bounds limit payload
bytes, not the descriptor index.
The reproducer uses a high-speed UAC2 device declaring bInterval 1 for
implicit feedback capture (8 packets) and bInterval 4 for playback
(1 packet). On the first capture completion after the stream starts, it
accesses seven descriptors spanning 112 bytes beyond the one-packet URB:
BUG: KASAN: slab-out-of-bounds in prepare_playback_urb (sound/usb/pcm.c:1560)
Write of size 4 at addr ffff88801e696ad0 by task vhci_rx/178
prepare_playback_urb (sound/usb/pcm.c:1560)
prepare_outbound_urb (sound/usb/endpoint.c:340)
snd_usb_queue_pending_output_urbs (sound/usb/endpoint.c:501)
snd_complete_urb (sound/usb/endpoint.c:1834)
__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657)
usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741)
vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107)
kthread (kernel/kthread.c:436)
The buggy address belongs to the object at ffff88801e696a00
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes to the right of
allocated 208-byte region [ffff88801e696a00, ffff88801e696ad0)
Record the allocated packet count per endpoint and clamp both the adopted
count and the packet-size copy to it. Fold the Format Type II delimiter
into urb_packs before the allocation loop so the recorded limit matches
every URB.
Fixes: cf044e441902 ("ALSA: usb-audio: Update the number of packets properly at receiving")
Reported-by: co+8eacd4fa193b1b28@bugs.sh
Closes: https://lore.kernel.org/all/22xPn8drvIUtYgVeQnBiNqXuevOTpBAjepLz%40bugs.sh/
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://patch.msgid.link/20260912200530.1955491-1-xmei5@asu.edu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Although we tried to fix the potential UAF issues at USB disconnect on
bcd2000 driver, there is still an overlooked case -- namely, when a
rawmidi trigger callback has been already running at USB disconnect
handling, the in-flight function (e.g. bcd2000_midi_send()) could
still access the URB, because the previous URB NULL-check & clearance
was considered only for the URB complete callbacks, but not about the
parallel rawmidi operations.
For addressing the race, this patch introduced a new spinlock that
covers each rawmidi operation as well as the rawmidi handling in the
complete callback. The URB is cleared with the lock, so it guarantees
that the pending rawmidi task already finished or a NULL check is
effective.
Fixes: 459d3a64766f ("ALSA: bcd2000: clear the URB pointers on disconnect")
Link: https://patch.msgid.link/20260910155227.996210-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The hwdep mmap callback rejects read-buffer mappings that are initially
writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ.
A process that can open the hwdep node O_RDWR can later use mprotect() to
make the mapping writable.
The read allocation begins with struct usb_stream. Its read_size member is
used by the fault handler to decide which pages belong to the read buffer.
The read VMA intentionally remains expandable because pcm_usb_stream uses
mremap() after reading that size. Changing read_size first can therefore
map and access pages beyond the allocation. The same member is also
consumed by usb_stream_free(), where changing it can make
free_pages_exact() release pages outside the allocation.
Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially
writable VMA. This keeps the separate output-buffer mapping writable while
preventing later permission upgrades.
Fixes: 030a07e44129 ("ALSA: Add USB US122L driver")
Cc: stable@vger.kernel.org
Signed-off-by: Kazuki Hanai <hnkz.64@gmail.com>
Link: https://patch.msgid.link/20260908110053.2950767-1-hnkz.64@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP Elite x3 Lap Dock is a laptop-like external display device with a
FHD screen, a keyboard, and a MT touchpad. It can be connected via USB-C
or Miracast. As an e-waste collector, I recently brought one for 69 CNY
(10.2 USD). The price already indicates how broken the device's design
and compatibility are ;-P
When connecting via USB-C, the video source is, of course, DisplayPort
Alternate Mode. However, the audio source has nothing to do with the
DisplayPort signal and is actually from a builtin UAC device.
The builtin UAC device provides three Alternate Settings:
- 1:1 - Capture, S16_LE, 8000/32000/44100/48000Hz
- 2:1 - Playback, S16_LE, 48000Hz
- 2:2 - Playback, S24_3LE, 48000Hz
Unfortunately, the last one is broken because:
- it doesn't accept SET_CUR(SAMPLE_RATE). QUIRK_FLAG_FIXED_RATE works
around it, however...
- it constantly produces severe harmonic distortion once the capture
stream is also opened. The interface 2 must be closed and reopened to
make it recover. IOW, simply closing the capture stream makes no
difference.
Considering that S24_3LE offers no additional benefit on small speakers
compared to S16_LE, and 2:1 is always usable as an alternative, skip 2:2
to get rid of the trouble.
Setting chip->setup to any non-default value disables the fixup and
reenables 2:2 (in this case QUIRK_FLAG_FIXED_RATE is required).
Quirky device sample:
usb 7-1.4: new full-speed USB device number 50 using xhci_hcd
usb 7-1.4: New USB device found, idVendor=03f0, idProduct=0c56, bcdDevice= 0.00
usb 7-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 7-1.4: Product: HP Elite x3 Lap Dock
usb 7-1.4: Manufacturer: HP
usb 7-1.4: Found last interface = 0
usb 7-1.4: 1:1: add audio endpoint 0x81
usb 7-1.4: Creating new data endpoint #81
usb 7-1.4: 1:1 Set sample rate 48000, clock 0
usb 7-1.4: 2:1: add audio endpoint 0x1
usb 7-1.4: Creating new data endpoint #1
usb 7-1.4: 2:1 Set sample rate 48000, clock 0
usb 7-1.4: 2:2: add audio endpoint 0x1
usb 7-1.4: 2:2 Set sample rate 48000, clock 0
usb 7-1.4: 2:2: cannot set freq 48000 to ep 0x1
usb 7-1.4: [9] FU [Sidetone Playback Switch] ch = 1, val = 0/1/1
usb 7-1.4: cannot set ctl value: req = 0x4, wValue = 0x200, wIndex = 0x900, type = 4, data = 0x40/0x0
usb 7-1.4: [9] FU [Sidetone Playback Volume] ch = 1, val = -17664/0/128
usb 7-1.4: [2] FU [Headset Playback Switch] ch = 1, val = 0/1/1
usb 7-1.4: [2] FU [Headset Playback Volume] ch = 2, val = -18944/0/1
usb 7-1.4: [6] FU [Headset Capture Switch] ch = 1, val = 0/1/1
usb 7-1.4: [6] FU [Headset Capture Volume] ch = 2, val = -18944/0/1
input: HP HP Elite x3 Lap Dock Consumer Control as /devices/pci0000:00/0000:00:08.3/0000:c9:00.4/usb7/7-1/7-1.4/7-1.4:1.3/0003:03F0:0C56.0033/input/input129
input: HP HP Elite x3 Lap Dock as /devices/pci0000:00/0000:00:08.3/0000:c9:00.4/usb7/7-1/7-1.4/7-1.4:1.3/0003:03F0:0C56.0033/input/input130
hid-generic 0003:03F0:0C56.0033: input,hiddev100,hidraw8: USB HID v1.11 Device [HP HP Elite x3 Lap Dock] on usb-0000:c9:00.4-1.4/input3
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260908-uac-hp-elite-x3-lap-dock-v1-2-e226cfe4038e@rong.moe
|
|
A switch statement is more readable than the current if blocks.
Also sort the cases in an ascending order.
As an interesting effect, this shrinks the size of quirks.o by 64 bytes
(GCC 16 -O2 x86_64):
text data bss total filename (before)
15266 12279 0 27545 quirks.o
text data bss total filename (before)
15202 12279 0 27481 quirks.o
Signed-off-by: Rong Zhang <i@rong.moe>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260908-uac-hp-elite-x3-lap-dock-v1-1-e226cfe4038e@rong.moe
|
|
The Behringer UV1 is a microphone audio processor with a USB audio
interface, which experiences periodic stutters unless implicit_fb is used.
This seems to be a similar device to the Behringer UMC series, so I
copied the quirks from those. I've confirmed that my own UV1 works great
with these flags set.
Signed-off-by: Nick Pegg <nick@nickpegg.com>
Link: https://patch.msgid.link/20260906155616.1625465-1-nick@nickpegg.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
After a power cycle and reenumeration, the Behringer CM1A* leaves its
MIDI endpoint inoperative. USB enumeration and driver binding
complete successfully, but MIDI outputs remain pending.
A GET_DESCRIPTOR request for the device descriptor, issued after USB
configuration, makes the endpoint operational. Add a one time boot quirk
to perform that request before ALSA initializes the device.
*
ID 1397:1234 BEHRINGER International GmbH CM1A
Signed-off-by: Sebastian Dalfuß <sd@sedf.de>
Link: https://patch.msgid.link/apwG4DRfNyvmRzyb@sedf.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
i_usx2y_in04_int() processes the interrupt URB data without checking
urb->actual_length. A short transfer from a malfunctioning device
would cause the handler to process uninitialized heap data from the
kmalloc-allocated in04_buf, which is then copied to the mmap-accessible
ctl_snapshot[] array.
Fix by using kzalloc() for in04_buf to zero-initialize the buffer,
and adding an actual_length check to skip processing on short
transfers while still resubmitting the URB.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Link: https://patch.msgid.link/20260904205826.4071119-2-tristmd@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The in04_last array in struct usx2ydev is declared as char[24], but
in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes.
In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization
path):
memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last));
This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes
past the end of the source object.
Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct
us428_ctls) and use it consistently for the in04_last array, the
in04_buf allocation, the URB transfer length, and the comparison loop,
replacing the bare 24 and 21 literals throughout.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Link: https://patch.msgid.link/20260904205826.4071119-1-tristmd@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The USB 6fire driver uses URBs embedded in different structs for PCM,
MIDI and communication, and this is basically a buggy implementation
nowadays; since a URB is managed with a refcount, this may lead to a
UAF when the URB is released asynchronously.
For addressing the problem, this patch converts those embedded URBs to
ones that are properly allocated via usb_alloc_urb(). The
pcm_urb.packets[] is gone, as it's allocated by usb_alloc_urb(), hence
it's found in urb.iso_frame_desc[] instead.
The conversions are rather straightforward; each embedded struct urb
is changed to a pointer, and its callers are updated accordingly.
The resource for those structs are released in the common destructor
functions (usb6fire_comm_free(), etc), which are called at both the
init error path and the disconnect.
No functional changes, only compile-tested.
Link: https://lore.kernel.org/20260903130757.0668310a.michal.pecio@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260903160458.1938392-4-tiwai@suse.de
|
|
The hiface driver uses URBs embedded in struct pcm_urb, and this is
basically a buggy implementation nowadays; since a URB is managed with
a refcount, this may lead to a UAF when the URB is released
asynchronously.
For addressing the problem, this patch converts the embedded URBs to
ones that are properly allocated via usb_alloc_urb().
The conversion is rather straightforward; pcm_urb.instance became a
pointer, assigned/freed via usb_alloc_urb() and usb_free_urb(), and
the call with this is corrected accordingly.
Along with it, the resource release is done in the common destructor
that is called from both at the error path and the disconnect.
No functional changes, only compile-tested.
Link: https://lore.kernel.org/20260903130757.0668310a.michal.pecio@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260903160458.1938392-3-tiwai@suse.de
|
|
UA101 driver uses URBs embedded in struct ua101, and this is basically
a buggy implementation nowadays; since a URB is managed with a
refcount, this may lead to a UAF when the URB is released
asynchronously.
For addressing the problem, this patch converts the embedded URBs to
ones that are properly allocated via usb_alloc_urb(). The
iso_frame_desc[] is gone, as it's allocated together by
usb_alloc_urb().
Along with the dynamic allocation of each URB, the ua101.urbs[]
becomes a static array of struct ua101_urb, and struct ua101_urb
contains the pointer to struct ua101. Those are needed to handle the
ready_list linked list in the complete callback.
No functional changes, only compile-tested.
Link: https://lore.kernel.org/20260903130757.0668310a.michal.pecio@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260903160458.1938392-2-tiwai@suse.de
|
|
The epq_in_urb object belonging to the caiaq device is coupled within
the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL)
executes successfully, epq_in_urb is successfully added to the urbp_list
queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD
layer driver for the caiaq USB device).
When init_card() calls snd_usb_caiaq_send_command() which subsequently
fails due to a timeout, and proceeds to call snd_card_free() to release
the card, the embedded ep1_in_urb object is also freed. When the dummy
HCD driver detects that the URB has been unlinked, it returns the URB
(by usb_hcd_giveback_urb()), which triggers [1].
Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch
to using a pointer instead. Separately allocate and manage the memory for
ep1_in_urb to prevent the release of the snd_card memory object from
interfering with it.
midi_out_urb has the same issue as ep1_in_urb and is handled in the same
way.
[1]
BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96
Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29
Call Trace:
usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96
dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019
__run_hrtimer kernel/time/hrtimer.c:2067 [inline]
__hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124
hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141
Allocated by task 36:
snd_card_new+0x7b/0x110 sound/core/init.c:184
create_card sound/usb/caiaq/device.c:429 [inline]
snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544
Freed by task 36:
snd_card_free_when_closed sound/core/init.c:630 [inline]
snd_card_free+0x138/0x1d0 sound/core/init.c:662
snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553
Fixes: 523f1dce3743 ("[ALSA] Add Native Instrument usb audio device support")
Reported-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=832ce9fa3face1b7d44d
Tested-by: syzbot+832ce9fa3face1b7d44d@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@sina.com>
Link: https://patch.msgid.link/20260903130521.554840-1-eadavis@sina.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
