<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/sound/usb, branch linux-rolling-stable</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2026-09-11T09:50:45+00:00</updated>
<entry>
<title>ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output()</title>
<updated>2026-09-11T09:50:45+00:00</updated>
<author>
<name>HyeongJun An</name>
<email>sammiee5311@gmail.com</email>
</author>
<published>2026-09-01T09:04:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=9d81885d97cba7796d1f8edc88f2499c8296f5b9'/>
<id>urn:sha1:9d81885d97cba7796d1f8edc88f2499c8296f5b9</id>
<content type='text'>
commit e4637ce34607f1733a34a57294966d26b263e626 upstream.

The snd_usbmidi_us122l_output() picks a count of 2 on anything slower
than high speed and never relates it to ep-&gt;max_transfer.  The URB
buffer holds exactly max_transfer bytes, so a device declaring a one
byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the
memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX.

Only 0x800e and 0x800f are pinned to nine bytes.  The US-122MKII at
0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the
USB core only clamps downward.

The akai and novation output ops in this file were given the same guard
recently.  Do the same here.

Fixes: 030a07e44129 ("ALSA: Add USB US122L driver")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An &lt;sammiee5311@gmail.com&gt;
Link: https://patch.msgid.link/20260901090409.1478573-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: FCP: do not copy out an uninitialised init response</title>
<updated>2026-09-07T15:37:22+00:00</updated>
<author>
<name>Baul Lee</name>
<email>baul.lee@xbow.com</email>
</author>
<published>2026-08-05T01:38:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=29ab2df278ab4f1d238cd9c1c393ee00db175cba'/>
<id>urn:sha1:29ab2df278ab4f1d238cd9c1c393ee00db175cba</id>
<content type='text'>
commit 4335e387786479889e6db691fe06d345e52ea536 upstream.

fcp_ioctl_init() allocates its response buffer with kmalloc() and copies
the whole buffer back to userspace:

	buf_size = init.step0_resp_size + init.step2_resp_size;

	void *resp __free(kfree) =
		kmalloc(buf_size, GFP_KERNEL);
	...
	if (copy_to_user(arg-&gt;resp, resp, buf_size))
		return -EFAULT;

Nothing clears the buffer, and the only writer of its leading
step0_resp_size bytes is the step-0 control transfer:

	err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
		FCP_USB_REQ_STEP0,
		USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN,
		0, private-&gt;bInterfaceNumber,
		step0_resp, private-&gt;step0_resp_size);
	if (err &lt; 0)
		return err;

usb_fill_control_urb() does not set URB_SHORT_NOT_OK, so a short or
zero-length data stage completes with status 0 and snd_usb_ctl_msg()
returns a small actual_length.  The only check is err &lt; 0, so a short
transfer is accepted as success.

snd_usb_ctl_msg() copies the full size back unconditionally:

	buf = kmemdup(data, size, GFP_KERNEL);
	...
	memcpy(data, buf, size);

Bytes the device never wrote are therefore restored into resp unchanged
and copied to userspace.  step0_resp_size and step2_resp_size are each
validated only to 1..255, so the caller also picks the slab cache, from
kmalloc-8 up to kmalloc-512.

On 7.2.0-rc5 (arm64), device answering step 0 with a zero-length data
stage, s0 = s2 = 255:

  # init_on_alloc off, no spray
  step0 window [0,255): nonzero=94/255
  000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01
  010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff

  # same kernel, kmalloc-512 pre-seeded with an 8-byte tag
  step0 window [0,255): nonzero=219/255  tagbytes=232

  # identical run, init_on_alloc=1
  step0 window [0,255): nonzero=0/255  tagbytes=0

  # all three runs
  step2 window [255,510): device words matched=62/62

a8 c4 5f 80 00 80 ff ff is the little-endian kernel text address
ffff8000805fc4a8.  The step-2 window is unaffected, so the disclosure is
exactly the step-0 region.

Zero the buffer, and require the step-0 transfer to deliver the full
step0_resp_size bytes so a short data stage is reported as an error.

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/20260805013804.38839-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: bcd2000: clear the URB pointers on disconnect</title>
<updated>2026-09-07T15:37:21+00:00</updated>
<author>
<name>Baul Lee</name>
<email>baul.lee@xbow.com</email>
</author>
<published>2026-08-05T01:34:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=b06ebc7fe25a6af4a9f6e4a3d4236a4178ad4b01'/>
<id>urn:sha1:b06ebc7fe25a6af4a9f6e4a3d4236a4178ad4b01</id>
<content type='text'>
commit 459d3a64766f5ca2f1886daeaf24582831a5f5ab upstream.

bcd2000_free_usb_related_resources() frees both URBs and leaves the
pointers behind:

	usb_kill_urb(bcd2k-&gt;midi_out_urb);
	usb_kill_urb(bcd2k-&gt;midi_in_urb);

	usb_free_urb(bcd2k-&gt;midi_out_urb);
	usb_free_urb(bcd2k-&gt;midi_in_urb);

The rawmidi device outlives that call.  A substream that is still open
when the device is unplugged reaches bcd2000_midi_send() from the
trigger path on close.  That function writes to the freed URB and then
hands it to the USB core:

	bcd2k-&gt;midi_out_urb-&gt;transfer_buffer_length = BUFSIZE;
	...
	ret = usb_submit_urb(bcd2k-&gt;midi_out_urb, GFP_ATOMIC);

usb_kill_urb() does not stop a later submission either, so a submit that
races the disconnect can requeue the URB after it has been reaped.
midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits
it from the completion handler.

KASAN on 7.2.0-rc5 (arm64):

  BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000]
  Write of size 4 at addr ffff00001827d388 by task bpoc/168
   __asan_store4
   bcd2000_midi_send [snd_bcd2000]
   bcd2000_midi_output_trigger [snd_bcd2000]
   snd_rawmidi_kernel_write1
   close_substream.part.0
  Freed by task 168:
   usb_free_urb
   bcd2000_disconnect [snd_bcd2000]

  BUG: KASAN: slab-use-after-free in usb_submit_urb
  Read of size 8 at addr ffff00001827d3b8 by task bpoc/168

Clear both pointers after freeing and test them on the paths that can
still run.  Poison the URBs before freeing them: usb_poison_urb() waits
for a running completion handler and rejects any later submission, so
after it returns the input path is quiesced and only the rawmidi trigger
path can still reach bcd2000_midi_send().  No unpoison is needed; the
URBs are freed on the next line.

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

Fixes: b47a22290d58 ("ALSA: MIDI driver for Behringer BCD2000 USB device")
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/20260805013428.38204-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: 6fire: bound the MIDI event length from the device</title>
<updated>2026-09-07T15:37:21+00:00</updated>
<author>
<name>Baul Lee</name>
<email>baul.lee@xbow.com</email>
</author>
<published>2026-08-05T01:34:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=34816e2cfeabafb8eccf54687186ce25699e8363'/>
<id>urn:sha1:34816e2cfeabafb8eccf54687186ce25699e8363</id>
<content type='text'>
commit a478893b59e36cfe7d77a76b352f2db55502e879 upstream.

usb6fire_comm_receiver_handler() forwards a MIDI event using a length
byte the device supplies, with no bound and no check that the transfer
delivered that many bytes:

	if (!urb-&gt;status) {
		if (rt-&gt;receiver_buffer[0] == 0x10) /* midi in event */
			if (midi_rt)
				midi_rt-&gt;in_received(midi_rt,
						rt-&gt;receiver_buffer + 2,
						rt-&gt;receiver_buffer[1]);
	}

receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so
only 62 bytes follow the two-byte header.  receiver_buffer[1] is a u8 the
device chooses, so a device that answers with 0x10 and a length of 0xFF
makes snd_rawmidi_receive() read 255 bytes starting two bytes into a
64-byte object.  The bytes past the buffer are handed to userspace
through the rawmidi read path.

urb-&gt;actual_length is not consulted either, so a short transfer leaves
both the type byte and the length byte at their previous values and the
handler acts on stale data.

The receiver URB is submitted from usb6fire_comm_init() at probe, so the
read happens on plug with no user action; forwarding to userspace also
needs a MIDI input substream open, since usb6fire_midi_in_received()
only calls snd_rawmidi_receive() when rt-&gt;in is set.

KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device:

  BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive
  Read of size 255 at addr ffff000009f64682 by task bash/183
   __asan_memcpy
   snd_rawmidi_receive
   usb6fire_midi_in_received [snd_usb_6fire]
   usb6fire_comm_receiver_handler [snd_usb_6fire]
  Allocated by task 11:
   usb6fire_comm_init [snd_usb_6fire]
   usb6fire_chip_probe [snd_usb_6fire]
  The buggy address is located 2 bytes inside of
   allocated 64-byte region [ffff000009f64680, ffff000009f646c0)

Reject the event when the length exceeds the bytes that follow the
header, and require the transfer to have delivered the header plus that
many bytes.  The receiver URB is submitted with a 64-byte
transfer_buffer_length, so a genuine device cannot deliver an event
longer than those 62 bytes and nothing valid is dropped.

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

Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB")
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/20260805013423.38175-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: Complete cleanup after system-resume errors</title>
<updated>2026-09-02T12:33:21+00:00</updated>
<author>
<name>Will Porter</name>
<email>mrwillporter@gmail.com</email>
</author>
<published>2026-08-24T22:57:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=d1f643b1c0258bd519146f7a342bbb394d413912'/>
<id>urn:sha1:d1f643b1c0258bd519146f7a342bbb394d413912</id>
<content type='text'>
commit 1739a976312e110c93a8dee66a1cdf893a1b187e upstream.

A failed system resume can leave the card unusable until reboot.
usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or
snd_usb_mixer_resume() fails. The error path skips the out: block, which
restores D0 and decrements chip-&gt;num_suspended_intf.

The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in
snd_power_ref_and_wait(). USB core logs an interface resume callback error.
It does not retry that callback, so a later callback cannot complete the
skipped cleanup.

usb_audio_suspend() increments num_suspended_intf before returning success.
A system-resume callback must consume the system-suspend count even if a
component resume fails. Otherwise, the stranded count skews later suspend
and resume cycles.

Do not apply this cleanup to runtime-resume errors. Runtime PM can retry
-EAGAIN or -EBUSY without another suspend callback. The count must continue
to describe that suspended interface. Other runtime-resume errors latch
runtime_error in the PM core and do not cause an immediate callback retry.

Both parts of the system-resume error path are longstanding. Commit
88a8516a2128a ("ALSA: usbaudio: implement USB autosuspend") introduced
err_out past the D0 restore. Commit 862b2509d157c ("ALSA: usb-audio: Fix
inconsistent card PM state after resume") later moved
num_suspended_intf-- into the out: block. The error path now skips both
operations.

No third-party code is needed to reach the error path.
snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the
result of usb_submit_urb() for devices that have a mixer status URB. Its
mixer-&gt;private_resume hook can also fail through scarlett2_init_notify().
snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It
can return -EPIPE or -EIO when the device stalls the request.

Route a component error through out: only when system_suspend is nonzero.
Continue to return runtime-resume errors through err_out. Later component
resume stages remain skipped. The original error still reaches USB core.
A later transfer can fail if the device did not recover.

I reproduced the system-resume failure on an Audient iD14 MkI with an
out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched
core left control readers in uninterruptible sleep in
snd_power_ref_and_wait() until a reboot. With this patch, the same failure
restored control access. A second system suspend and resume also succeeded
after I disabled fault injection.

Assisted-by: Claude:claude-opus-5
Assisted-by: Antigravity:gemini-3.1-pro-high
Assisted-by: Codex:gpt-5.6-sol
Fixes: 88a8516a2128a ("ALSA: usbaudio: implement USB autosuspend")
Fixes: 862b2509d157c ("ALSA: usb-audio: Fix inconsistent card PM state after resume")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Will Porter &lt;mrwillporter@gmail.com&gt;
Link: https://patch.msgid.link/20260824225757.26749-1-mrwillporter@gmail.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output()</title>
<updated>2026-09-02T12:33:21+00:00</updated>
<author>
<name>Marouane El Moufid</name>
<email>eun0us@espilon.net</email>
</author>
<published>2026-08-23T13:55:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=1074c2306901b44ebcb83855583c6776e1e392ea'/>
<id>urn:sha1:1074c2306901b44ebcb83855583c6776e1e392ea</id>
<content type='text'>
commit 1035a8f63bae28e498b0e7b5ac91d749844a7158 upstream.

snd_usbmidi_novation_output() lays out a two-byte header at
transfer_buffer[0..1] and passes &amp;transfer_buffer[2] together with a
length of ep-&gt;max_transfer - 2 to snd_rawmidi_transmit():

	count = snd_rawmidi_transmit(ep-&gt;ports[0].substream,
				     &amp;transfer_buffer[2],
				     ep-&gt;max_transfer - 2);

ep-&gt;max_transfer comes from the output endpoint's wMaxPacketSize via
usb_maxpacket(). A malformed or malicious device can advertise a bulk
OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this
value downwards - so ep-&gt;max_transfer becomes 1 and the count argument
becomes -1.

snd_rawmidi_transmit() passes the negative count on to
__snd_rawmidi_transmit_peek(), where "if (count1 &gt; count) count1 = count"
leaves count1 negative; get_aligned_size() keeps it negative for a
byte-stream substream, so the following memcpy(buffer, ..., count1) runs
with a (size_t)-1 length and writes far past the transfer buffer, which
was allocated with usb_alloc_coherent(ep-&gt;max_transfer).

This is the same class of bug that was fixed for snd_usbmidi_akai_output()
in commit 0970274613fb ("ALSA: usb-audio: fix OOB write in
snd_usbmidi_akai_output()"); the novation output routine was left
unguarded. Bail out when the endpoint cannot hold the two-byte header
plus at least one payload byte.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Marouane El Moufid &lt;eun0us@espilon.net&gt;
Link: https://patch.msgid.link/178749334830.543645.13722252148340572274@espilon.net
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: Fix sample rates for PreSonus AudioBox USB</title>
<updated>2026-09-02T12:33:21+00:00</updated>
<author>
<name>Trevor Vorhees</name>
<email>vorhees-work@proton.me</email>
</author>
<published>2026-08-12T00:44:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=8bf1cdb6d05c144874e3c24801443d9db5577bde'/>
<id>urn:sha1:8bf1cdb6d05c144874e3c24801443d9db5577bde</id>
<content type='text'>
commit 21e958c4fd92d63139039430c246613505480689 upstream.

The fixed audio formats for the PreSonus AudioBox USB specify a discrete
rate mask but leave nr_rates at zero and rate_table unset.  find_format()
therefore rejects every requested rate, preventing the playback and
capture streams from being opened.

Add the advertised 44100 and 48000 Hz rates to both streams and report
their 24 significant bits.

Fixes: 34fe4a9df247 ("ALSA: usb-audio: Add quirk for PreSonus AudioBox USB")
Cc: stable@vger.kernel.org
Signed-off-by: Trevor Vorhees &lt;vorhees-work@proton.me&gt;
Link: https://patch.msgid.link/20260811-audiobox-usb-fix-v1-1-13c8b7f071ea@proton.me
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: scarlett2: Use a private URB for the notification endpoint</title>
<updated>2026-08-27T12:35:21+00:00</updated>
<author>
<name>Geoffrey D. Bennett</name>
<email>g@b4.vu</email>
</author>
<published>2026-08-09T18:06:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=ecd2f83a4ddc078901e7104144cb6c5e5db3b7cf'/>
<id>urn:sha1:ecd2f83a4ddc078901e7104144cb6c5e5db3b7cf</id>
<content type='text'>
commit cd17d6ff7b7d2b1dd9bcc80ae7b4a83773f918c6 upstream.

scarlett2_init_notify() used mixer-&gt;urb, which
snd_usb_mixer_status_create() allocates for the UAC2 status interrupt
endpoint and mixer.c manages. On a device with that endpoint, the
"already in use" check fires on the status URB and returns 0 for
success without doing anything. No notification URB is submitted, and
cmd_done is left zeroed because it is initialised past that check and
nowhere else. scarlett2_usb_init() then issues SCARLETT2_USB_INIT_1
and wait_for_completion_timeout() would crash adding to the zeroed
wait.head.

Use a separate URB in scarlett2_data, as done for FCP, and initialise
cmd_done in scarlett2_init_private(). mixer.c was also freeing the URB
in snd_usb_mixer_free() and resubmitting it in
snd_usb_mixer_activate(), so scarlett2 must now do both: add
scarlett2_cleanup_urb(), called from private_free and private_suspend,
and a private_resume callback to re-establish the URB after resume.
scarlett2_init_notify() is reached from there, and the URB kill path
in scarlett2_notify() completes cmd_done, leaving a stale count that
would satisfy the next command's wait before the device ACKs. Use
reinit_completion() to clear it.

Also free the URB if the transfer buffer allocation fails, and both if
usb_submit_urb() fails. Move scarlett2_init_notify() up next to
scarlett2_cleanup_urb() so scarlett2_init_private() can reference it
without a forward declaration.

Fixes: 1b65088958ca ("ALSA: scarlett2: Implement handling of the ACK notification")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Geoffrey D. Bennett &lt;g@b4.vu&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Link: https://patch.msgid.link/ffb8ba37d5d605dfdfd8576949d67098651f9349.1786290885.git.g@b4.vu
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: FCP: Use a private URB for the notification endpoint</title>
<updated>2026-08-27T12:35:21+00:00</updated>
<author>
<name>Geoffrey D. Bennett</name>
<email>g@b4.vu</email>
</author>
<published>2026-08-09T18:06:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=6db3c1d7e2872c9904e05ca8e0515920776a3c9c'/>
<id>urn:sha1:6db3c1d7e2872c9904e05ca8e0515920776a3c9c</id>
<content type='text'>
commit 918b8d231c571c50a00efe92ffc8404a537a0490 upstream.

fcp_init_notify() used mixer-&gt;urb, which snd_usb_mixer_status_create()
allocates for the optional UAC2 status interrupt endpoint and mixer.c
kills, resubmits and frees. On a device with that endpoint,
fcp_init_notify()'s "already set up" early return fires on the status
URB and returns success without doing anything. No FCP notification
URB is submitted, and cmd_done is left zeroed because it is
initialised past that early return and nowhere else. fcp_init() then
issues init1_opcode and wait_for_completion_timeout() would crash
adding to the zeroed wait.head. fcp_cleanup_urb() would also kill and
free mixer.c's status URB.

Use a separate URB in fcp_data, and initialise cmd_done in
fcp_init_private() where fcp_data is allocated. fcp_init_notify() is
reached again after suspend via fcp_reinit(), and the URB kill path in
fcp_notify() completes cmd_done, leaving a stale count that would
satisfy the next command's wait before the device ACKs. Use
reinit_completion() to clear it.

Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Geoffrey D. Bennett &lt;g@b4.vu&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Link: https://patch.msgid.link/2cad281e6434024ca48a9ecc94fa19d6777e9be7.1786290885.git.g@b4.vu
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ALSA: usb-audio: Fix mixer regression on SteelSeries Arctis Nova 5</title>
<updated>2026-08-08T15:51:59+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2026-08-08T15:22:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=885c22d259c8b245c479f3e19e9eeee54dee8b24'/>
<id>urn:sha1:885c22d259c8b245c479f3e19e9eeee54dee8b24</id>
<content type='text'>
The recent "sticky mixer" sanity check in USB-audio driver caused a
regression on SteelSeries Arctis Nova 5 (1038:2232); because the
firmware doesn't handle GET_CUR requests, some mixers are effectively
disabled, leading to the too low / soft volumes:
  usb 5-1.1: 9:0: sticky mixer values (-19712/0/256 =&gt; 0), disabling
  usb 5-1.1: 10:0: sticky mixer values (-21248/0/256 =&gt; 0), disabling

Restore the functionality by ignoring GET_CUR errors intentionally
with MIXER_GET_CUR_BROKEN quirk.

Fixes: 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers")
Reported-by: Gert Burger &lt;gertburger@gmail.com&gt;
Closes: https://lore.kernel.org/CAEQ1D3kdA3mkQx7ei9Kq0gwky0qroJqCLKrkvgfkqgTbeu086A@mail.gmail.com
Link: https://bbs.archlinux.org/viewtopic.php?id=314220
Link: https://patch.msgid.link/20260808152258.1948767-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
</feed>
