linux-toradex.git/sound/usb/caiaq, branch master Linux kernel for Apalis and Colibri modules ALSA: caiaq: Use strscpy() in snd_usb_caiaq_input_init() 2026-10-21T12:58:16+00:00 Thorsten Blum blum@kernel.org 2026-10-21T10:39:29+00:00 8045043c9d66508b5ebfd702e555b9642b5aa805 To prepare for removing strlcat() from the kernel [1], use strscpy() instead with the length returned by usb_make_path() as the append offset. No functional change. Link: https://github.com/KSPP/linux/issues/370 [1] Signed-off-by: Thorsten Blum <blum@kernel.org> Link: https://patch.msgid.link/20261021103928.131918-2-blum@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> 
To prepare for removing strlcat() from the kernel [1], use strscpy()
instead with the length returned by usb_make_path() as the append
offset.

No functional change.

Link: https://github.com/KSPP/linux/issues/370 [1]
Signed-off-by: Thorsten Blum <blum@kernel.org>
Link: https://patch.msgid.link/20261021103928.131918-2-blum@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: caiaq: Fix races at MIDI URB and trigger accesses 2026-10-09T12:39:17+00:00 Takashi Iwai tiwai@suse.de 2026-10-08T19:25:46+00:00 52b1213e2a086f2828500ab9c8bac45b213429bb URB completion and rawmidi trigger callbacks can race with each other, which may put the state inconsistent, causing double submissions, etc. Guard both with a new spinlock for avoiding the races. Fixes: f3f80a9205da ("ALSA: caiaq - Fix Oops with MIDI") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261008192553.300025-7-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> 
URB completion and rawmidi trigger callbacks can race with each other,
which may put the state inconsistent, causing double submissions, etc.

Guard both with a new spinlock for avoiding the races.

Fixes: f3f80a9205da ("ALSA: caiaq - Fix Oops with MIDI")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20261008192553.300025-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: caiaq: Register card at the final step 2026-10-09T12:39:04+00:00 Takashi Iwai tiwai@suse.de 2026-10-08T19:25:45+00:00 441533711d91492815b710a79b1ec4acb5e19ca6 caiaq driver calls snd_card_register() before creating the mixer elements, which is rather confusing to user-space, as the devices have been published before adding the control elements. Swap the call order to make the card registration as the final step (as written in the comment). Fixes: 8e3cd08ed8e5 ("[ALSA] caiaq - add control API and more input features") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20261008192553.300025-6-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> 
caiaq driver calls snd_card_register() before creating the mixer
elements, which is rather confusing to user-space, as the devices have
been published before adding the control elements.

Swap the call order to make the card registration as the final step
(as written in the comment).

Fixes: 8e3cd08ed8e5 ("[ALSA] caiaq - add control API and more input features")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20261008192553.300025-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: caiaq: Allow zero-length packet handling for EP1 2026-10-07T09:27:31+00:00 Takashi Iwai tiwai@suse.de 2026-10-06T13:44:04+00:00 ccfe6ab672c020fca56988e634088bfb7764e2a7 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 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>
ALSA: caiaq: Add LCD support for the Kore controllers 2026-09-28T16:11:37+00:00 Niko Huuskonen niko.huuskonen.00@gmail.com 2026-09-27T00:35:32+00:00 d243bb01c86cf7e6aaec53bf0eb8bac8c92ecffa 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 
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
ALSA: caiaq: Fix the Kore controller key map 2026-09-28T16:11:36+00:00 Niko Huuskonen niko.huuskonen.00@gmail.com 2026-09-27T00:35:30+00:00 c0508fc6895137f9e2dd43c1a09cc834254cc149 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 
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
ALSA: caiaq: Serialize access to the EP1 command buffer 2026-09-28T16:11:36+00:00 Niko Huuskonen niko.huuskonen.00@gmail.com 2026-09-27T00:35:29+00:00 a718fd03e1e00211cf4662f5ab82d33f4c18e2a7 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 
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
ALSA: caiaq: unregister the input device when probe fails 2026-09-28T11:43:26+00:00 Nguyen Ngoc Thang ngocthang2710.1999@gmail.com 2026-09-25T17:07:17+00:00 0b7bd20f6379bc5e431fd74d866390f5b5b63f3c 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> 
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>
ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev 2026-09-06T08:00:47+00:00 Edward Adam Davis eadavis@sina.com 2026-09-03T13:05:21+00:00 402a9d6aab7ac787ab075adeb562c3db8b8f564b 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> 
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>
ALSA: caiaq: Fix potential double-free at error path 2026-09-03T16:08:24+00:00 Takashi Iwai tiwai@suse.de 2026-09-03T10:38:51+00:00 3b26ceef88c110f4d188387cffa0df78657be904 The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared. Link: https://sashiko.dev/#/patchset/20260903084747.535367-1-eadavis%40sina.com Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Link: https://patch.msgid.link/20260903103855.1807838-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> 
The fix for caiaq driver's resource management to handle the errors
tries to release the resources in a common destructor call, but as a
sashiko review for another patch suggested, some of the audio
resources such as URBs have been already freed, and this may lead to a
double-free.

For addressing the double-free, call the common destructor function
from each place, and assure that the resource pointers get cleared.

Link: https://sashiko.dev/#/patchset/20260903084747.535367-1-eadavis%40sina.com
Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly")
Link: https://patch.msgid.link/20260903103855.1807838-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>