Hi Salvatore,
thanks a lot for the quick reply.
It really is an upstream problem. It works with the upstream 6.12.113
kernel but fails with 6.12.115.
I dissected it and only built about 10 kernels, haven't done this in
years ;)
output of last 'git bisect bad':
---
81e4b0009f2acc841d77a24fd796528b0bf62c4e is the first bad commit
commit 81e4b0009f2acc841d77a24fd796528b0bf62c4e (HEAD)
Author: Edward Adam Davis <[email protected]>
Date: Tue Jan 13 16:29:23 2026 +0800
ALSA: usb-audio: Prevent excessive number of frames
[ Upstream commit ef5749ef8b307bf8717945701b1b79d036af0a15 ]
In this case, the user constructed the parameters with maxpacksize 40
for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The
buffer
size for each data URB is maxpacksize * packets, which in this example
is 40 * 6 = 240; When the user performs a write operation to send audio
data into the ALSA PCM playback stream, the calculated number of frames
is packsize[0] * packets = 264, which exceeds the allocated URB buffer
size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].
Added a check for the number of single data URB frames when calculating
the number of frames to prevent [1].
[1]
BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460
sound/usb/pcm.c:1487
Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506
Call Trace:
copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487
prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611
prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=6db0415d6d5c635f72cb
Tested-by: [email protected]
Signed-off-by: Edward Adam Davis <[email protected]>
Link:
https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
sound/usb/pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
output of 'git bisect log':
---
git bisect start
# Status: warte auf guten und schlechten Commit
# good: [7fdb7c1824a1f9979d648d7ae28ac446bcee9c6e] Linux 6.12.113
git bisect good 7fdb7c1824a1f9979d648d7ae28ac446bcee9c6e
# Status: warte auf schlechten Commit, 1 guter Commit bekannt
# bad: [03bae623ec326c2738198739625832aab0eb120a] Linux 6.12.115
git bisect bad 03bae623ec326c2738198739625832aab0eb120a
# bad: [9afcfc4c6597547c20d6354fa68f1d6012e31c0e] wifi: iwlwifi: dvm:
pair transport op-mode enter/leave
git bisect bad 9afcfc4c6597547c20d6354fa68f1d6012e31c0e
# bad: [33201705179d94985c788ae9186ceeab044fb6bd] ceph: Remove uses of
page from ceph_process_folio_batch()
git bisect bad 33201705179d94985c788ae9186ceeab044fb6bd
# good: [39870dbccdea99e1aa0ae445ab913748e912a352] ASoC: Intel: avs: Use
topology information for endpoint numbers
git bisect good 39870dbccdea99e1aa0ae445ab913748e912a352
# bad: [58a4c2dbe6f746cdf9ea06fcaeda535aecb4b80b] bnxt_en: Update
firmware interface spec to 1.10.3.85
git bisect bad 58a4c2dbe6f746cdf9ea06fcaeda535aecb4b80b
# good: [20b3c72c1b83054c568d2322a95e217fdc281bc3] bpf: Mark
bpf_refcount field as unique
git bisect good 20b3c72c1b83054c568d2322a95e217fdc281bc3
# bad: [4eca06a55417c3b2e538656d12c89e224343653e] bpf: Fix exception
exit lock checking for subprogs
git bisect bad 4eca06a55417c3b2e538656d12c89e224343653e
# bad: [f8b8ec0ddde74066d4452a7a961da544f193e00f] riscv: trace: fix
snapshot deadlock with sbi ecall
git bisect bad f8b8ec0ddde74066d4452a7a961da544f193e00f
# good: [f32ae3cfc976074e9c5927893ce49bcf12f53748] idpf: fix error
handling in the init_task on load
git bisect good f32ae3cfc976074e9c5927893ce49bcf12f53748
# good: [d1e9614a142eff34c93e94a15a71ad0e806799c4] virtio_net: Fix
misalignment bug in struct virtnet_info
git bisect good d1e9614a142eff34c93e94a15a71ad0e806799c4
# bad: [81e4b0009f2acc841d77a24fd796528b0bf62c4e] ALSA: usb-audio:
Prevent excessive number of frames
git bisect bad 81e4b0009f2acc841d77a24fd796528b0bf62c4e
# first bad commit: [81e4b0009f2acc841d77a24fd796528b0bf62c4e] ALSA:
usb-audio: Prevent excessive number of frames
---
I hope this helps!
Best regards
Benjamin
Am 03.11.26 um 17:13 schrieb Salvatore Bonaccorso:
Control: tags -1 + moreinfo upstream
Hi Benjamin,
On Mon, Nov 02, 2026 at 10:14:00PM +0100, Benjamin Scherrer wrote:
Package: src:linux
Version: 6.12.115-2
Severity: normal
X-Debbugs-Cc: [email protected]
Dear Maintainer,
I am experiencing a reproducible USB audio regression with a MOTU M4 interface
on current Debian 13.
The interface has worked reliably for years. After rebooting into kernel
6.12.115+deb13.1-amd64, audio playback stopped working.
Booting the same system with kernel 6.12.113 restores normal operation. No
other configuration changes were made.
Sorry about the breakage with the security update needed. As you can
cleary identify when system is regression, could you please bisect the
changes between 6.12.113 and 6.12.115 upstream with the following
procedure to identify the culprit please?
git clone --single-branch -b linux-6.12.y
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v6.12.113
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_defconfig
# test 6.12.113 to ensure this is "good"
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem does not exist
# test 6.12.115 to ensure this is "bad"
git checkout v6.12.35
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem exists
With that confirmed, the bisection can start:
git bisect start
git bisect good v6.12.113
git bisect bad v6.12.115
In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:
make my_defconfig
make -j $(nproc) bindeb-pkg
... install, verify if problem exists
and if the problem is hit run:
git bisect bad
and if the problem doesn't trigger run:
git bisect good
. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.
Iterate until git announces to have identified the first bad commit.
Then provide the output of
git bisect log
In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.
Regards,
Salvatore
