<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/sound/usb, branch v7.2-rc7</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc7</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc7'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-08-07T08:35:31+00:00</updated>
<entry>
<title>ALSA: usb-audio: Fix sticky mixer regressions on M-Audio Fast Track Ultra</title>
<updated>2026-08-07T08:35:31+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2026-08-07T08:34:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a8934c2c6dfd72901cf3cc0de28e85eb902a61a4'/>
<id>urn:sha1:a8934c2c6dfd72901cf3cc0de28e85eb902a61a4</id>
<content type='text'>
The recent fix for sticky mixer volumes caused regressions of M-audio
Fast Track Ultra device, where the mixer state is kept to the default
value.

Add the quirk entries to tolerate the broken mixer behavior.  As the
device is known to work in the implicit feedback mode, explicitly
enable the implicit feedback mode, too.

Since there are two FTU models that are almost identical, both entries
are added in this patch (0763:2080 and 0763:2081).

Fixes: 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers")
Link: https://bugzilla.suse.com/show_bug.cgi?id=1273166
Link: https://patch.msgid.link/20260807083418.1712585-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: usx2y: bound the hwdep mmap fault offset</title>
<updated>2026-08-05T07:37:27+00:00</updated>
<author>
<name>Baul Lee</name>
<email>baul.lee@xbow.com</email>
</author>
<published>2026-08-05T01:34:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2ca1eea3cd17930daffe9e429a7c89232036ec24'/>
<id>urn:sha1:2ca1eea3cd17930daffe9e429a7c89232036ec24</id>
<content type='text'>
snd_us428ctls_vm_fault() turns the faulting page offset into a kernel
address with no bound of any kind:

	offset = vmf-&gt;pgoff &lt;&lt; PAGE_SHIFT;
	vaddr = (char *)(...)-&gt;us428ctls_sharedmem + offset;
	page = virt_to_page(vaddr);
	get_page(page);
	vmf-&gt;page = page;

	return 0;

snd_us428ctls_mmap() checks only the length of the mapping, never the
offset, and us428ctls_sharedmem is a single page from
alloc_pages_exact().  For a character device file_mmap_size_max()
returns ULONG_MAX, so the mm layer imposes no ceiling either.  Every page
offset above zero resolves to a struct page outside the object, and the
handler installs it into the caller's address space read-write; the vma
is not marked read-only.

The caller picks the page frame with a single mmap() argument and gets
read-write access to a page of kernel memory it does not own; an offset
that lands in an unpopulated vmemmap region oopses instead.

A process that can open the hwdep node of an attached US-X2Y reaches
this after loading the FPGA image through the same node; no capability
check is involved.

On 7.2.0-rc5 (arm64), mmap() with a large offset:

  Unable to handle kernel paging request at virtual address fffffdffc45d5ac8
  pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]
  Call trace:
   snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]
   __do_fault
   __handle_mm_fault
   handle_mm_fault
   el0_da

Reject any offset outside the shared region.  The pcm hwdep handler in
usx2yhwdeppcm.c computes its address the same way and needs the same
bound.

Discovered by XBOW, triaged by Baul Lee &lt;baul.lee@xbow.com&gt;

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Federico Kirschbaum &lt;federico.kirschbaum@xbow.com&gt;
Reported-by: Baul Lee &lt;baul.lee@xbow.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee &lt;baul.lee@xbow.com&gt;
Link: https://patch.msgid.link/20260805013445.38283-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: fix OOB write on Type II inbound URBs</title>
<updated>2026-08-05T07:35:28+00:00</updated>
<author>
<name>Baul Lee</name>
<email>baul.lee@xbow.com</email>
</author>
<published>2026-08-05T01:34:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=69ee44e1a23be62318189dc4b37fa4ad94053269'/>
<id>urn:sha1:69ee44e1a23be62318189dc4b37fa4ad94053269</id>
<content type='text'>
data_ep_set_params() sizes each URB transfer buffer before it adds the
Format Type II transfer delimiter:

	u-&gt;packets = urb_packs;
	u-&gt;buffer_size = maxsize * u-&gt;packets;

	if (fmt-&gt;fmt_type == UAC_FORMAT_TYPE_II)
		u-&gt;packets++; /* for transfer delimiter */
	u-&gt;urb = usb_alloc_urb(u-&gt;packets, GFP_KERNEL);

buffer_size is computed from the pre-increment packet count and never
recomputed, so for a Type II endpoint the buffer is one packet short of
the packet count the URB is built with.

prepare_inbound_urb() then lays out one iso frame per packet and never
consults buffer_size:

	offs = 0;
	for (i = 0; i &lt; urb_ctx-&gt;packets; i++) {
		urb-&gt;iso_frame_desc[i].offset = offs;
		urb-&gt;iso_frame_desc[i].length = ep-&gt;curpacksize;
		offs += ep-&gt;curpacksize;
	}

	urb-&gt;transfer_buffer_length = offs;
	urb-&gt;number_of_packets = urb_ctx-&gt;packets;

The last descriptor therefore points one packet past the end of the
transfer buffer, where the host controller writes device data on every
inbound transfer.  prepare_silent_urb() and prepare_playback_urb() bound
their fill loops by ctx-&gt;buffer_size, so only capture is affected.

fmt_type comes from the device's audio streaming descriptors, so any
device advertising a Type II capture format hits this once userspace sets
hw_params on the stream.

KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report
per inbound transfer:

  BUG: KASAN: slab-out-of-bounds in dummy_timer
  Write of size 64 at addr ffff0000186171c0 by task cons02/166
   __asan_memcpy
   dummy_timer
   hrtimer_run_softirq
  Allocated by task 166:
   usb_alloc_coherent
   snd_usb_endpoint_set_params
  The buggy address is located 0 bytes to the right of
   allocated 64-byte region [ffff000018617180, ffff0000186171c0)

Compute buffer_size after the delimiter packet has been accounted for,
and bound the fill loop by buffer_size, as prepare_silent_urb() already
does on the outbound side.  This grows every Type II URB allocation by
one maxsize packet.

Discovered by XBOW, triaged by Baul Lee &lt;baul.lee@xbow.com&gt;

Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model")
Reported-by: Federico Kirschbaum &lt;federico.kirschbaum@xbow.com&gt;
Reported-by: Baul Lee &lt;baul.lee@xbow.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee &lt;baul.lee@xbow.com&gt;
Link: https://patch.msgid.link/20260805013441.38245-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: us144mkii: re-anchor capture URBs on resubmission</title>
<updated>2026-08-04T16:06:37+00:00</updated>
<author>
<name>Baul Lee</name>
<email>baul.lee@xbow.com</email>
</author>
<published>2026-08-04T12:36:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2615f0fb90df8cf5a96133ca4be74294ed288604'/>
<id>urn:sha1:2615f0fb90df8cf5a96133ca4be74294ed288604</id>
<content type='text'>
capture_urb_complete() resubmits each capture URB without anchoring it:

	usb_get_urb(urb);
	ret = usb_submit_urb(urb, GFP_ATOMIC);

Anchoring is a property of a submission, not of the URB.  The giveback
path calls usb_unanchor_urb() before urb-&gt;complete(), so an URB
resubmitted from its own completion handler is off the anchor.  The
capture URBs are anchored once, at stream start, so from the first
completion onward tascam-&gt;capture_anchor is empty.

tascam_free_urbs(), tascam_disconnect(), tascam_suspend() and the
stop-work path all call usb_kill_anchored_urbs(&amp;tascam-&gt;capture_anchor)
to reap the capture URBs before anything is freed.  With the anchor empty
those calls return immediately and the URBs stay queued on the host
controller.

tascam_free_urbs() then returns the capture transfer buffers with
usb_free_coherent(), and snd_card_free() releases the snd_card
allocation that embeds tascam (card-&gt;private_data).  The controller
completes the queued URBs afterwards, writing device-supplied data into
the freed transfer buffer, and capture_urb_complete() dereferences the
freed driver object.

KASAN on 7.2.0-rc5 (arm64):

  BUG: KASAN: slab-use-after-free in dummy_timer
  Write of size 512 at addr ffff000015b62000
   __asan_memcpy
   dummy_timer
   hrtimer_run_softirq
  Allocated by task 64:
   usb_alloc_coherent
   tascam_alloc_urbs
   tascam_probe
  Freed by task 170:
   usb_free_coherent
   tascam_free_urbs
   tascam_disconnect
   usb_unbind_interface

  BUG: KASAN: slab-use-after-free in capture_urb_complete
  Read of size 4 at addr ffff0000170ee878
  Freed by task 170:
   release_card_device
   snd_card_free
   tascam_disconnect

Restore the usb_anchor_urb() between the reference count bump and the
resubmission.  That also makes the handler's usb_unanchor_urb() failure
arm meaningful again and restores usb_kill_anchored_urbs() as a barrier
on the disconnect, suspend and stop-work paths.

The anchoring was removed on the premise that the URB is already anchored
from the initial submission, which does not hold once the first giveback
has run.

Discovered by XBOW, triaged by Baul Lee &lt;baul.lee@xbow.com&gt;

Fixes: 5cff1529a2f9 ("ALSA: us144mkii: capture_urb_complete: redundant usb_anchor_urb corrupts anchor list on each resubmission")
Reported-by: Federico Kirschbaum &lt;federico.kirschbaum@xbow.com&gt;
Reported-by: Baul Lee &lt;baul.lee@xbow.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee &lt;baul.lee@xbow.com&gt;
Link: https://patch.msgid.link/20260804123625.91769-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: FCP: fix OOB write in fcp_meter_ctl_get()</title>
<updated>2026-08-04T16:05:50+00:00</updated>
<author>
<name>Baul Lee</name>
<email>baul.lee@xbow.com</email>
</author>
<published>2026-08-04T12:36:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=620f1e52a46f604635efd0fb78138afd6a513b5d'/>
<id>urn:sha1:620f1e52a46f604635efd0fb78138afd6a513b5d</id>
<content type='text'>
fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size
by the driver's own limit of 255

	if (map.map_size &lt; 1 || map.map_size &gt; 255 ||
	    map.meter_slots &lt; 1 || map.meter_slots &gt; 255)
		return -EINVAL;

and passes it to fcp_add_new_ctl() as the control's channel count, where
it is stored as elem-&gt;channels.

Every control read writes into struct snd_ctl_elem_value, whose integer
array is declared long value[128], so the limit is 128, not 255.
fcp_meter_ctl_get() stores one 64-bit word per channel into that array
with no bound of its own:

	for (i = 0; i &lt; elem-&gt;channels; i++) {
		int idx = private-&gt;meter_level_map[i];
		int value = idx &lt; 0 ? 0 : le32_to_cpu(resp[idx]);

		ucontrol-&gt;value.integer.value[i] = value;
	}

snd_ctl_elem_read_user() serves that object from
memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of
kmalloc-2048.  offsetof(struct snd_ctl_elem_value, value) is 72, so
element i is written at byte 72 + 8 * i and element 144 already lands
past the allocation.  At map_size 255 the last store ends at byte 2112,
888 bytes past the object and 64 bytes into the adjacent slab object.
The stored words come from the device and meter_level_map[] selects
which word lands in which slot, so extent and contents are both
controlled.

The core does not catch this.  snd_ctl_check_elem_info() is reached only
from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under
CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a
compile-time true.  __snd_ctl_add_replace() validates kcontrol-&gt;count and
never inspects elem-&gt;channels.

Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives
the hwdep descriptor that created it, so the out-of-bounds stores are
issued by any process able to read controls on /dev/snd/controlC0.

KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read:

  BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get
  Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185
   __asan_store8
   fcp_meter_ctl_get
   snd_ctl_elem_read
   snd_ctl_ioctl
  Allocated by task 185:
   memdup_user
   snd_ctl_ioctl
  The buggy address is located 0 bytes to the right of
   allocated 1224-byte region [ffff000017af0000, ffff000017af04c8)

Bound the map size by the ABI limit rather than by 255, and bound the
store loop at the sink so it cannot run past the value array whatever
elem-&gt;channels holds.

Discovered by XBOW, triaged by Baul Lee &lt;baul.lee@xbow.com&gt;

Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver")
Reported-by: Federico Kirschbaum &lt;federico.kirschbaum@xbow.com&gt;
Reported-by: Baul Lee &lt;baul.lee@xbow.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee &lt;baul.lee@xbow.com&gt;
Link: https://patch.msgid.link/20260804123611.91715-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN for Logitech PRO X 2 LIGHTSPEED</title>
<updated>2026-08-03T07:37:12+00:00</updated>
<author>
<name>Rong Zhang</name>
<email>i@rong.moe</email>
</author>
<published>2026-07-31T13:45:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c973e61895db8fe4a69d8b33de92068d135cafd8'/>
<id>urn:sha1:c973e61895db8fe4a69d8b33de92068d135cafd8</id>
<content type='text'>
The UAC mixer of the Logitech PRO X 2 LIGHTSPEED has broken mixer
GET_CUR behavior but otherwise works fine.

Add a quirk table entry matching VID/PID=0x046d/0x0af7 and apply the
MIXER_GET_CUR_BROKEN quirk flag to make the mixer usable again.

Quirky device sample (after applying the quirk flag):

  usb 3-2.1: New USB device found, idVendor=046d, idProduct=0af7, bcdDevice= 1.00
  usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  usb 3-2.1: Product: PRO X 2 LIGHTSPEED
  usb 3-2.1: Manufacturer: Logitech
  usb 3-2.1: SerialNumber: 0000000000000000
  usb 3-2.1: 2:0: broken mixer GET_CUR (-18944/0/256 =&gt; -2662)
  usb 3-2.1: 6:0: broken mixer GET_CUR (-18944/0/256 =&gt; 0)

Fixes: 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers")
Suggested-by: Brian van den Berg &lt;faxuser@proton.me&gt;
Reported-by: Brian van den Berg &lt;faxuser@proton.me&gt;
Link: https://lore.kernel.org/all/370007e6-b73b-4bfc-8410-a860781c7ad7@proton.me/
Signed-off-by: Rong Zhang &lt;i@rong.moe&gt;
Link: https://patch.msgid.link/20260731-uac-lg-pro-x-2-ls-v1-1-268eaefe66ab@rong.moe
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: Add GET_SAMPLE_RATE quirk for C-Media CM6206</title>
<updated>2026-07-29T06:31:42+00:00</updated>
<author>
<name>Mikhail Gavrilov</name>
<email>mikhail.v.gavrilov@gmail.com</email>
</author>
<published>2026-07-28T22:22:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e93bb6f3acec5b70a5567efe78f1a96148a7291f'/>
<id>urn:sha1:e93bb6f3acec5b70a5567efe78f1a96148a7291f</id>
<content type='text'>
The C-Media CM6206 (0d8c:0102) truncates the three-byte sample rate it
returns for UAC_GET_CUR to its two low bytes.  After the rate has been
set to 96000 (0x017700) the device reports back 30464 (0x007700).

At probe time the driver initializes every altsetting to its maximum
rate, so altsetting 5 is set to 96000 and the warning appears on each
plug-in, before anything has opened the device:

  usb 3-1.3: 1:5 Set sample rate 96000, clock 0
  usb 3-1.3: current rate 30464 is different from the runtime rate 96000

That altsetting is the one parse_audio_format_rates_v1() already fixes
up for this chip, so this affects every CM6206.

Only the read-back is broken, the rate itself is applied: a 1 kHz sine
rendered at 96 kHz is recovered at 1000.2 Hz, and a silent fallback to
48000 would have been reported as 0x00bb80 rather than as the low half
of the requested rate.

Add a QUIRK_FLAG_GET_SAMPLE_RATE entry for the device so the read-back
is skipped.  Setting the same flag through the quirk_flags module
parameter makes the warning disappear while the 96000 init still
happens.

Signed-off-by: Mikhail Gavrilov &lt;mikhail.v.gavrilov@gmail.com&gt;
Link: https://patch.msgid.link/20260728222239.62749-1-mikhail.v.gavrilov@gmail.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: Clamp frame size in implicit-feedback mode</title>
<updated>2026-07-29T06:25:27+00:00</updated>
<author>
<name>Sonali Pradhan</name>
<email>sonalipradhan@google.com</email>
</author>
<published>2026-07-28T20:24:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8d7a30c50c2e58a6839634ed0acde14466d1dc61'/>
<id>urn:sha1:8d7a30c50c2e58a6839634ed0acde14466d1dc61</id>
<content type='text'>
snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's
stride and stores the result directly in out_packet-&gt;packet_size[i]. If a
connected USB device sends an oversized sync packet, this frame count can
exceed ep-&gt;maxframesize.

The un-clamped frame count then propagates to the playback endpoint queue,
potentially driving packet transfers beyond the endpoint's hardware frame
limits.

Cap the calculated frame count against ep-&gt;maxframesize in
snd_usb_handle_sync_urb() to prevent oversized packets from entering the
playback queue.

Fixes: 28acb12014fb ("ALSA: usb-audio: use sender stride for implicit feedback")
Cc: stable@vger.kernel.org
Assisted-by: Jetski:Gemini-3.6-Flash
Signed-off-by: Sonali Pradhan &lt;sonalipradhan@google.com&gt;
Link: https://patch.msgid.link/20260728202432.2354994-1-sonalipradhan@google.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set</title>
<updated>2026-07-29T06:23:32+00:00</updated>
<author>
<name>Sonali Pradhan</name>
<email>sonalipradhan@google.com</email>
</author>
<published>2026-07-28T20:17:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d0199ae1666ff9ae2d1d568d64c3430d4c47f0e5'/>
<id>urn:sha1:d0199ae1666ff9ae2d1d568d64c3430d4c47f0e5</id>
<content type='text'>
When a USB audio endpoint requests full packet transfers via the fill_max
descriptor flag, data_ep_set_params() promotes ep-&gt;curpacksize to
ep-&gt;maxpacksize. However, maxsize is left at the original sample-rate
derived value.

Since u-&gt;buffer_size is allocated as maxsize * packets, the resulting
DMA buffer is far too small for the requested transfer length. When the
USB host controller streams up to curpacksize bytes per packet, it writes
past the end of the buffer via DMA, corrupting kernel heap memory.

Update maxsize to curpacksize when fill_max is set so that the allocated
DMA buffer size matches the actual transfer request size.

[ changed to reassign maxsize only when ep-&gt;fill_max is set -- tiwai ]

Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model")
Cc: stable@vger.kernel.org
Assisted-by: Jetski:Gemini-3.6-Flash
Signed-off-by: Sonali Pradhan &lt;sonalipradhan@google.com&gt;
Link: https://patch.msgid.link/20260728201716.2347726-1-sonalipradhan@google.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision)</title>
<updated>2026-07-28T16:30:43+00:00</updated>
<author>
<name>Robert Abrahamse</name>
<email>denobyte2@gmail.com</email>
</author>
<published>2026-07-28T14:03:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cee046679655b4822f76efc9658f19efee9ac979'/>
<id>urn:sha1:cee046679655b4822f76efc9658f19efee9ac979</id>
<content type='text'>
Add USB mixer mapping quirk for later revisions of the Corsair Virtuoso
headset with USB IDs 0x1b1c:0x0a43 (wired) and 0x1b1c:0x0a44
(wireless). These devices exhibit the same mixer label collision as
earlier Virtuoso variants: all controls are labelled "Headset", causing
applications like PulseAudio to move the sidetone control instead of
the main playback volume.

Signed-off-by: Robert Abrahamse &lt;denobyte2@gmail.com&gt;
Link: https://patch.msgid.link/20260728140314.11601-1-denobyte2@gmail.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
</feed>
