Replace six sprintf() calls that write to
SNDRV_CTL_ELEM_ID_NAME_MAXLEN-sized buffers with snprintf() to avoid
potential buffer overflows.
Signed-off-by: Bob Song <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260812033030.635417-1-songxiebing@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ca0132_free() and dbpro_free() call kfree(codec->spec) without
setting codec->spec to NULL afterward, leaving a dangling pointer.
Set it to NULL.
Signed-off-by: Bob Song <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260812033019.635010-1-songxiebing@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
hda_bus_match() has an unreachable 'return 1' after an if/else that
covers both branches. Remove the superfluous return and simplify the
control flow by dropping the else branch.
hdac_codec_match() uses a redundant if/else to return 1 or 0.
Simplify to a single return statement.
Signed-off-by: Bob Song <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260812033007.633564-1-songxiebing@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: 34fe4a9df2 ("ALSA: usb-audio: Add quirk for PreSonus AudioBox USB")
Cc: stable@vger.kernel.org
Signed-off-by: Trevor Vorhees <vorhees-work@proton.me>
Link: https://patch.msgid.link/20260811-audiobox-usb-fix-v1-1-13c8b7f071ea@proton.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The bounce_error_event() embeds the failed event in the bounce payload
by pointing data.ext.ptr at it. When that event is a queued
variable-length event, its own data.ext.ptr holds the address of its
first extension cell, put there by snd_seq_event_dup(). The payload
goes out verbatim through snd_seq_expand_var_event(), so the address
reaches userspace.
That is the same address commit 705dd6dcbc ("ALSA: seq: Clear
variable event pointer on read") removed from the event header. The
read path still clears it there, just above the call that expands the
payload.
Embed a sanitised copy instead, treated exactly as snd_seq_read()
treats the header. A stack copy is enough because delivery is
synchronous and snd_seq_event_dup() copies before returning.
An unprivileged client reaches this by setting SNDRV_SEQ_FILTER_BOUNCE,
queueing a variable-length event to a port that does not exist and
reading the bounce back. Eight bytes on 64-bit, from its own pool.
Fixes: efc86691e4 ("ALSA: seq: Fix kernel heap address leak in bounce_error_event()")
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260811131835.3837024-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ThinkPad X1 Carbon 6th Gen (ALC285, SSID 17aa:225c) has no physical
Line Out jack. The 3.5mm headphone jack is wired to the headphone DAC,
but the ALSA HDA driver names the corresponding control as
"Line Out Playback Volume" (node 0x02).
PipeWire's ALSA Card Profile (ACP) silences "Line Out" when headphones
are activated, which incorrectly mutes the headphone output.
Add a quirk to rename the control to "Headphone Playback Volume" via
alc285_lenovo_dac_rename().
Tested on openSUSE Tumbleweed (kernel 7.1.5):
- Control renamed successfully, no name collision with "Headphone Playback Switch"
- Headphone output works across multiple PipeWire/WirePlumber restarts
and port switches
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221522
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Tested-by: Branislav Klocok <branislav.klocok@orava.sk>
Link: https://patch.msgid.link/20260811062734.400512-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Replace manual ioremap() calls with pcim_iomap() which uses devres
for automatic cleanup. This eliminates the need for manual iounmap()
in both the error path of asihpi_adapter_probe() and the
asihpi_adapter_remove() function.
The pcim_iomap() helper is cleaner and less error-prone since it
handles unmapping automatically when the PCI device is released.
Assisted-by: opencode/big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260811042122.44923-1-rosenp@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Lenovo Legion Pro 5 16ADR10 (codec SSID 0x17aa:0x3926) suffers from
distorted/crackling speaker output, as only one speaker pin is driven
without proper COEF/amp initialization.
Add HDA_CODEC_QUIRK applying ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN
to enable both speaker pins and proper amp initialization, restoring
clean audio output at all volume levels.
Tested: Both internal speaker pairs are now driven correctly and
distortion is gone; headphone output remains unaffected.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221595
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Tested-by: Efe Yılmaz <efe.tcyilmaz@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260811024902.134457-3-zhangheng@kylinos.cn
The UMP sequencer client protects its output rawmidi file (out_rfile)
with an rwlock (output_lock). seq_ump_process_event(), the port's
event_input callback, reads out_rfile.output under read_lock on every
delivered UMP event, while the open/close paths (serialized by
ump->open_mutex) publish and clear out_rfile under write_lock.
Output is opened/closed only on the subscribe/use lifecycle while
delivery happens per event, so this is another read-mostly hot path.
Convert it to RCU and drop the rwlock. out_rfile is an embedded struct
rather than a pointer, so instead of restructuring it, add an
RCU-protected shadow of the substream (out_substream) for the reader;
out_rfile itself becomes writer-only state accessed solely under
open_mutex. The reader now runs lock-free under rcu_read_lock() via
rcu_dereference(), and open publishes the substream with
rcu_assign_pointer().
On close the substream is cleared with rcu_assign_pointer(NULL) and the
rawmidi is released only after synchronize_rcu(), so no reader in the
delivery path can still be writing to the substream when
snd_rawmidi_kernel_release() runs.
Dropping write_lock_irqsave() from the writers is safe: they run in
process context under open_mutex, and the sole atomic reader now uses
RCU, which is IRQ-safe.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260810133711.42483-6-tiwai@suse.de
Each virmidi device keeps a list of its opened input files (filelist)
protected by both an rwlock (filelist_lock) and a rw_semaphore
(filelist_sem). snd_virmidi_dev_receive_event() walks the list on the
sequencer event input path -- read_lock() when the event is delivered in
atomic context, down_read() otherwise -- decoding each incoming event
into the file's rawmidi buffer. The writers (input open/close) take both
locks to add/remove entries.
This is another typical dual-lock read-mostly pattern as the port
subscriber list: files are opened/closed rarely while the receive
callback runs per event. Let's convert the traversal to RCU and drop
the rwlock; the existing filelist_sem keeps serializing the writers.
The atomic input path now runs lock-free under rcu_read_lock(), and
both readers share a single list_for_each_entry_rcu() (valid under the
rwsem via lockdep_is_held()). The writers switch to
list_add_tail_rcu() / list_del_rcu().
snd_virmidi_input_close() freed the entry (parser and struct)
immediately after list_del. A concurrent lockless reader in the atomic
path may still be dereferencing it, so the close path now waits for an
RCU grace period after list_del_rcu() before freeing; synchronize_rcu()
is used rather than kfree_rcu() because the parser must also be released
after the grace period, not just the struct. Non-atomic readers are
already excluded by the down_write, so only the atomic RCU readers need
the grace period.
Dropping write_lock_irq() from the writers is safe: no writer runs in
atomic/IRQ context, and the sole atomic reader now uses RCU, which is
IRQ-safe.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260810133711.42483-5-tiwai@suse.de
The sequencer keeps a global table of clients (clienttab[]) indexed by
client id, protected by the global clients_lock spinlock. The lookup
snd_seq_client_use_ptr() reads a slot and takes a use_lock reference on
the client, and this runs on the event delivery hot path: every
dispatched event resolves its destination (and often source) client
through it. The spinlock's only job on the read side is to make the
"pointer is non-NULL" test and the reference increment indivisible with
respect to the writer that nulls the slot and then drains the refcount.
Clients come and go rarely but delivery happens constantly, so this is
yet another read-mostly case as the port and subscriber lists.
Convert the table to RCU: the read side now runs lock-free under
rcu_read_lock() and takes the use_lock reference via
rcu_dereference(), removing contention on the single global spinlock
from the delivery path. The writers keep clients_lock (still needed
to serialize slot allocation) and publish / unpublish via
rcu_assign_pointer(); creation and destruction remain serialized at a
higher level by register_mutex.
As with the ports, the client is not freed via kfree_rcu(): its lifetime
is governed by the use_lock refcount drained in seq_free_client1().
list_del under the old spinlock excluded a concurrent lookup from taking
a new reference once the slot was nulled; rcu_assign_pointer(NULL) offers
no such exclusion, so a reader still holding the old pointer can grab a
reference after the unpublish. seq_free_client1() therefore calls
synchronize_rcu() after nulling the slot and before snd_use_lock_sync():
once the grace period elapses no new reference can appear, and the
existing drain then frees the client safely.
clienttablock[] keeps its slot-reservation role (create/free are
serialized by register_mutex); its read on the lookup path only gates
module autoload, so a lockless read is harmless. Dropping the spinlock
from the read path is safe: clients_lock is now taken only by the
process-context writers, and the sole atomic reader uses RCU, which is
IRQ-safe.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260810133711.42483-4-tiwai@suse.de
Each sequencer client keeps a list of its ports (ports_list_head)
protected by both an rwlock (ports_lock) and a mutex (ports_mutex).
The rwlock is taken read-side on the event delivery hot path:
snd_seq_port_use_ptr() walks the list to resolve a port on every
dispatched event, while the mutex serializes port creation/deletion.
Ports change rarely but delivery happens constantly, so this is the
another read-mostly case as the port subscriber list. Convert the
port list traversal to RCU and drop the rwlock entirely; the existing
ports_mutex keeps serializing the writers. The atomic delivery path
(snd_seq_port_use_ptr(), snd_seq_port_query_nearest()) now runs
lock-free under rcu_read_lock() instead of contending on the shared
rwlock.
The writers switch to list_add_tail_rcu()/list_del_rcu().
snd_seq_insert_port() now stores the port number and name before
publishing the node so RCU readers only ever observe a fully
initialized port. One drawback is that snd_seq_delete_all_ports()
drops the O(1) splice trick and unlinks each port individually,
though: the splice repointed the last port's ->next away from the list
head, which would send a concurrent lockless reader off the end of the
list.
Unlike the subscriber objects, ports are not freed via kfree_rcu():
port_delete() must drain outstanding use_lock references (and run
private_free()) synchronously. The rwlock previously guaranteed that
no reader could take a new use_lock reference once the port was
unlinked -- list_del under write_lock excluded snd_use_lock_use()
under read_lock. list_del_rcu() offers no such exclusion, so a reader
still traversing the list can grab a reference after the unlink.
port_delete() therefore calls synchronize_rcu() after the port has
been unlinked and before snd_use_lock_sync(): once the grace period
elapses no new reference can appear, and the existing drain then frees
the port safely.
Dropping write_lock_irq() from the writers is safe: no writer runs in
atomic/IRQ context, and the sole atomic reader now uses RCU, which is
IRQ-safe.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260810133711.42483-3-tiwai@suse.de
Each sequencer port keeps two subscriber groups (c_src and c_dest),
each protected by both an rwlock (list_lock) and a rw_semaphore
(list_mutex). The rwlock is taken read-side in the event delivery hot
path (__deliver_to_subscribers()) for delivering every event to
subscribers, while the mutex serializes subscribe/unsubscribe and
covers the sleepable delivery and query walks.
Subscriptions change rarely but delivery happens constantly, so this is
a textbook read-mostly case. Convert the subscriber list traversal to
RCU and drop the rwlock entirely while keeping the existing list_mutex
for serializing the writers. The atomic delivery path now runs
lock-free under rcu_read_lock() instead of contending on the shared
rwlock.
Along with the conversion to RCU, the subscriber lists are switched
from list_head to hlist so that removal can use hlist_del_init_rcu():
it keeps the ->next pointer intact for concurrent readers while
clearing ->pprev, which lets the double-deletion guard (added in
commit 13d5e5d472) keep detecting an already-removed entry via
hlist_unhashed().
Dropping write_lock_irq() from the writers is safe: no writer runs in
atomic/IRQ context, and the sole atomic reader now uses RCU, which is
IRQ-safe. Port lifetime handling (use_lock/closing drain in
port_delete()) is orthogonal and unchanged.
Note that the conversion to RCU has another merit: it automatically
"fixes" the (rather false) lockdep warnings for the doubly read-locks
of the same subscriber list, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260810133711.42483-2-tiwai@suse.de
The HP EliteBook 6 G1a (SSID 103c:8e0d) uses a Realtek ALC236 codec.
Without a quirk no fixup is selected and the mic-mute LED stays off.
It needs the same ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk as the
already-supported 14" variant (SSID 103c:8dfb), so add it.
Signed-off-by: Denis Batishchev <ii343hbka@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260810151440.2306217-2-ii343hbka@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both the front headphone jack and the rear line-out jack play back
at a barely audible volume on the Beelink SER6 Max (ALC897, PCI subsystem
ID 1f66:0202), even with all mixer controls at 0dB. GPIO2 on the
codec gates an external headphone/line amplifier that the generic
parser never enables. Add a fixup that asserts it. Verified fixed
on both jacks.
Signed-off-by: Brian Koebbe <brian@koeb.be>
Link: https://patch.msgid.link/20260810145700.1206010-1-brian@koeb.be
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is managed by USB core and drivers aren't expected to touch it.
It should only be not NULL on a submitted URB, in which case clearing
defeats the "submitted while active" sanity check in usb_submit_urb()
and may crash the HCD handling the URB and panic the kernel.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Link: https://patch.msgid.link/20260810075728.483c827e.michal.pecio@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
scarlett2_init_notify() used mixer->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: 1b65088958 ("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 <g@b4.vu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/ffb8ba37d5d605dfdfd8576949d67098651f9349.1786290885.git.g@b4.vu
fcp_init_notify() used mixer->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: 46757a3e7d ("ALSA: FCP: Add Focusrite Control Protocol driver")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/2cad281e6434024ca48a9ecc94fa19d6777e9be7.1786290885.git.g@b4.vu
The BIOS of the F+ FLAPTOP r laptop (Realtek ALC897, SSID 1e63:6d9a)
declares only pin 0x1b, the headphone output of the 3.5 mm combo jack.
Every other external pin is left at 0x411111f0, so the headset mic pin
0x19 is never parsed and no headset mic input exists. The pin is wired
on this board - retasking it makes the headset mic record.
Reuse ALC897_FIXUP_HP_HSMIC_VERB, which already sets the pin config this
machine needs: 0x19 as a headset mic without its own presence detect.
Only 0x1b reports jack presence here, so a mic pin with presence detect
would leave the driver in auto-mic mode waiting for an event that never
arrives.
Without the quirk the generic parser retasks the lone headphone pin as
an input instead. That surfaces as a "Headphone Mic" input which records
only the internal mic bleed, so the headset mic appears present but dead.
Tested on ALT Linux, kernel 6.12, by recording a CTIA headset mic on the
combo jack with the internal mic as a reference.
ALSA info before the patch:
https://alsa-project.org/db/?f=18363eddea933baee100c9bf461d0e5cf74c8de2
ALSA info after the patch:
https://alsa-project.org/db/?f=48ae2cd7aaf1eb0f24639ce83cd38cfd93b25f76
Cc: stable@vger.kernel.org # 6.12.x
Signed-off-by: Ajrat Makhmutov <rauty@altlinux.org>
Link: https://patch.msgid.link/20260808185500.2564948-1-rauty@altlinux.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
set_sample_rate_v2v3() returns early when the clock already reports the
requested rate:
prev_rate = get_sample_rate_v2v3(chip, fmt->iface,
fmt->altsetting, clock);
if (prev_rate == rate)
goto validation;
A device advertising exactly one sample rate always takes this branch, so
it never receives a SET_CUR for CS_SAM_FREQ_CONTROL at all.
The Mackie DLZ Creator XS (0a73:003a, 14 in / 4 out, 48 kHz only) requires
that write. Without it the device drops off the USB bus roughly 0.2-1.8 s
into any stream, clearing its port CONNECTION bit; captured audio is
byte-correct until the instant it vanishes.
USBPcap traces of a cold-booted device on Windows show SET_CUR 48000 issued
unconditionally on every stream start, followed by clean streaming. The
device is otherwise driven with plain class-compliant UAC2 - it also works
on iOS, which cannot load a vendor driver - so no vendor-specific
initialization is involved.
The device is self-powered, so the resulting state survives a USB replug:
initializing it on any host that issues the write leaves it working on
Linux until it is power-cycled, which made the failure look intermittent.
Add a quirk flag rather than dropping the early exit, since the opposite
requirement also exists in-tree: QUIRK_FLAG_FIXED_RATE suppresses rate
setting for single-rate devices (JBL Quantum610/810). The two behaviors
are device-dependent and cannot both be the default.
A/B on identically cold-booted hardware, same kernel, same port, repeated
twice:
without the flag device dropped after 5-6 s, then again after 3-4 s
with the flag 20 s playback followed by 20 s of 14-channel capture,
960000 frames, zero re-enumerations
This change was developed with an AI coding assistant. The assistant did
the trace analysis that located the bug and wrote the patch and this
changelog; the hardware testing, the cold-boot cycles and the decision to
submit were the author's. Several earlier hypotheses it proposed - URB
queue depth, isochronous packet under-allocation, endpoint start ordering -
were disproven by measurement before this one.
The bug was located with usbmon on Linux and USBPcap on Windows, by
diffing an enumeration capture of a cold-booted device on each host.
Verified on physical hardware by the A/B above.
Assisted-by: Claude-Code:claude-opus-5
Signed-off-by: JJ Macalinao <jj@macalinao.org>
Link: https://patch.msgid.link/20260808172726.1107550-1-jj@macalinao.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The cvt_legacy_sysex_to_ump() initialises only the first word of the
output packet and ORs the data bytes into it. The second word is left
alone, and the conversion context is kept across calls, so it still
carries the previous packet's bytes. Those stale bits corrupt the new
data. Any SysEx longer than six data bytes is affected.
A SysEx with the twelve data bytes 01..0c comes out as:
30160102 03040506
30260708 0b0e0f0e
The second packet declares six data bytes and four of them are wrong,
inside the declared length.
The sibling cvt_legacy_cmd_to_ump() already clears the second word. Do
the same here.
Fixes: 0b5288f5fe ("ALSA: ump: Add legacy raw MIDI support")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260808014554.3550153-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The GA403UM (SSID 1043:1044) uses the same ALC285 codec + dual CS35L56
I2C amplifier topology as the GA403U and GA403W variants, which already
have quirk entries (1043:1b13, 1043:1024). Without the quirk, the
woofers sit on a separate DAC from the tweeters, so the hardware volume
control only scales part of the speaker system and the headset
microphone pins are not configured.
Apply the existing ALC285_FIXUP_ASUS_GA403U_HEADSET_MIC fixup to the
GA403UM as well.
Signed-off-by: Garrett Blackmon <garrett@blackmon.dev>
Link: https://patch.msgid.link/20260807150708.33785-1-garrett@blackmon.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The headphone jack is not detected on this Huawei Matebook (Conexant
SN6140 codec). The BIOS incorrectly marks Pin 0x18 as [N/A], causing
the driver to report hp_outs=0 and no "Headphones" output appears.
Override the pin configuration for NID 0x18 to set it as a headphone
jack, which restores proper detection and audio routing.
Link: https://github.com/thesofproject/sof/issues/10687
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260807125857.678297-4-zhangheng@kylinos.cn
On the ASUS Vivobook S14 S5406SA (subsystem 0x104310c4, Lunar Lake
platform) with an ALC294 codec, the headset microphone (3.5mm jack)
fails to capture any audio. Adding the ALC2XX_FIXUP_HEADSET_MIC
quirk resolves the issue and restores proper headset mic recording.
Link: https://github.com/thesofproject/linux/issues/5729
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260807125857.678297-3-zhangheng@kylinos.cn
The Acer Gadget E10 ETBook (subsystem 0x1e50:0x7036, Realtek ALC233)
has a left speaker that does not work by default. The BIOS fails to
properly configure pin 0x1b, leaving it unconnected.
Using hdajackretask to override pin 0x1b as "Internal Speaker"
restores left speaker functionality. Add a quirk to apply this pin
configuration automatically at probe time.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221435
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260807125857.678297-2-zhangheng@kylinos.cn
Inline headset buttons (play/pause, volume up/down) are unresponsive on
the Lenovo Yoga Pro 7 14ASP10. Enable headset jack handling by chaining
alc_fixup_headset_jack to the existing bass speaker fixup for this model.
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/IA1PR19MB77127DE4BC25300BAD284E30FCD22@IA1PR19MB7712.namprd19.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The HP Spectre x360 2-in-1 Laptop 16-aa0xxx with PCI subsystem ID
0x103c:0x8c17 only gets the CS35L41 amplifier setup from
ALC287_FIXUP_CS35L41_I2C_2, so the speaker-mute and mic-mute keyboard
LEDs do not work.
Use ALC245_FIXUP_HP_SPECTRE_X360_16_AA0XXX like subsystem ID 0x8c16 so
the mute LEDs work.
Tested on HP Spectre x360 2-in-1 Laptop 16-aa0xxx.
Signed-off-by: Shang En Sim <sim@shangen.org>
Link: https://patch.msgid.link/20260807055139.58707-1-sim@shangen.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Although portman2x4 driver has a check of the given devptr->id value,
it doesn't check for a negative id, which is often given as "none" or
such value when bound via sysfs. This may lead to OOB access for
index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range.
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260806153227.1460166-7-tiwai@suse.de
Although mts64 driver has a check of the given devptr->id value, it
doesn't check for a negative id, which is often given as "none" or
such value when bound via sysfs. This may lead to OOB access for
index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range.
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260806153227.1460166-6-tiwai@suse.de
virmidi driver blindly trusts that the given devptr->id value is
within the proper card index range at probe. It's OK for the devices
the driver itself creates at the module probe time, but if the device
is bound manually via sysfs interface, this could be -1 as "none", and
this leads to OOB access for index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range.
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260806153227.1460166-5-tiwai@suse.de
serial-u16550 driver blindly trusts that the given devptr->id value is
within the proper card index range at probe. It's OK for the devices
the driver itself creates at the module probe time, but if the device
is bound manually via sysfs interface, this could be -1 as "none", and
this leads to OOB access for index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range.
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260806153227.1460166-4-tiwai@suse.de
mpu401 driver blindly trusts that the given devptr->id value is within
the proper card index range at probe. It's OK for the devices the
driver itself creates at the module probe time, but if the device is
bound manually via sysfs interface, this could be -1 as "none", and
this leads to OOB access for index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range.
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260806153227.1460166-3-tiwai@suse.de
aloop driver blindly trusts that the given devptr->id value is within
the proper card index range at probe. It's OK for the devices the
driver itself creates at the module probe time, but if the device is
bound manually via sysfs interface, this could be -1 as "none", and
this leads to OOB access for index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range.
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260806153227.1460166-2-tiwai@suse.de
When opening a legacy rawmidi device for a UMP, it may re-open an
existing rawmidi device for appending to a substream, leading to a
lockdep warning due to rmidi->open_mutex taken twice -- but the
rawmidi devices are completely individual, hence it's a
false-positive.
For avoiding the warning, modify the helper to open a rawmidi instance
with a proper locking subclass from the UMP legacy open.
Unfortunately, there is no good way to achieve it with guard(), so
reverted to the manual mutex calls again.
Reported-by: syzbot+d10d58fc99caa0489796@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/6a6a9634.57649fcc.360844.000b.GAE@google.com
Link: https://patch.msgid.link/20260806101352.1291581-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ASUS UM6702RA/RC (subsystem 0x1043:0x1ee2) currently has two
duplicate quirk entries: one using HDA_CODEC_QUIRK with
ALC285_FIXUP_ASUS_I2C_SPEAKER2_TO_DAC1, and another using
SND_PCI_QUIRK with ALC287_FIXUP_CS35L41_I2C_2.
Since these entries cover the same machine, the duplicate is redundant
and should be merged. The correct fixup to keep is
ALC285_FIXUP_ASUS_I2C_SPEAKER2_TO_DAC1, as it additionally addresses
the issue where the volume cannot be adjusted properly.
Merge the two entries into a single SND_PCI_QUIRK entry with the
appropriate fixup.
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260806054505.43717-2-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ASUS Strix G615 series (subsystem IDs 0x1043:0x1204 and 0x1043:0x1214)
currently have duplicate quirk entries: one using HDA_CODEC_QUIRK with
ALC287_FIXUP_TAS2781_I2C, and another using SND_PCI_QUIRK with
ALC287_FIXUP_TXNW2781_I2C_ASUS.
Since these entries cover the same machines, the duplicate entries are
redundant and may cause confusion. The correct fixup for these models
should be ALC287_FIXUP_TXNW2781_I2C_ASUS, as the TAS2781 fixup was
likely a mistake.
Merge the two entries into a single SND_PCI_QUIRK entry with the
correct fixup, removing the redundant HDA_CODEC_QUIRK entries.
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260806054505.43717-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The mute LED on the HP Laptop 15-dy0xxx (PCI SSID 103c:864f, Realtek
ALC236) does not work, because the machine has no entry in the quirk
table. No fixup is applied, so no mute LED classdev is registered and
nothing ever drives the LED.
The LED is controlled by COEF index 0x07, bit 0. This was verified on
the hardware with hda-verb: setting the bit lights the mute LED and
clearing it turns the LED off.
hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x07
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x1 # LED on
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x200 # LED off
That is exactly what ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 configures, and
the closely related HP Laptop 15-dw0xxx (103c:85f0) already uses it.
Bit 9 (0x200) is set by default on this board and is preserved by the
fixup's read-modify-write.
Tested on an HP Laptop 15-dy0xxx (SKU 7FU54UA#ABA, board 864F,
BIOS F.40).
Signed-off-by: Carl Quist <equalizerjr@gmail.com>
Link: https://lore.kernel.org/CAOtcGaxXndKxTK5MVSEcmF-LUy+V51K7fhE=qvLA+VvW5ZyCNA@mail.gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The internal mic boost on the Positivo N15RPE-S is too high.
Fix this by applying the ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine
to limit the gain.
Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Link: https://patch.msgid.link/20260805154518.19093-1-edson.drosdeck@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add codec SSID entries for the Lenovo Legion R9000P ADR10H (83RV),
which uses the same ALC287 + AW88399 smart amplifier configuration
as the existing supported Legion models.
DSDT inspection confirms identical AWDZ8399 ACPI device layout with
reversed I2C addresses (0x35 before 0x34). Register dumps show the
same BSTS behavior as the other Legions. Both the channel swap and
BSTS bypass quirks apply.
Codec SSIDs (Lenovo vendor ID 0x17aa):
* 0x3936: Legion R9000P ADR10H (AMD)
* 0x3937: Legion R9000P ADR10H (AMD)
Signed-off-by: Marco Giunta <marco_giunta@outlook.it>
Link: https://patch.msgid.link/DS7PR19MB7724EE8DED946545C55717C1FCD32@DS7PR19MB7724.namprd19.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the subsystem ID 103c:8a0e to the ALC287 HP GPIO LED quirk
table so the mute LED follows the speaker mute state.
Tested on HP Pavilion Laptop 15-eh2xxx with ALC287 codec.
The mute LED now follows the speaker mute state.
Signed-off-by: Luca Castaldini <luca.castaldini96@gmail.com>
Link: https://patch.msgid.link/20260805122907.52302-1-luca.castaldini96@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Legion AW88399 speaker routing sends a stereo FL/FR stream
to both speaker pairs. A four-channel stream leaves the front
pair silent, so advertising four channels exposes an unusable
playback mode.
Limit the analogue PCM and the multi-output runtime constraint
to two channels for the affected Legion codec SSIDs. This
exposes the usable stereo configuration and rejects
four-channel playback.
Signed-off-by: Aaron Ma <mapengyu@gmail.com>
Reviewed-by: Marco Giunta <marco_giunta@outlook.it>
Tested-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260804185325.22861-2-mapengyu@gmail.com
The ALC287 codec on Lenovo Legion AW88399 laptops does not mark
the combo-jack microphone as a headset mic, so the HDA parser
treats it as a plain microphone. The headset microphone route
and inline headset buttons are therefore unavailable.
Enable Realtek headset mode without treating the jack as a
headphone microphone, and enable headset jack button handling.
Suppress automatic microphone selection so the internal microphone
remains selectable while a headset is connected.
The existing 0x1d override is redundant: firmware already marks
that pin unused, and the override triggers a "SKU not ready
0x411111f0" warning. Drop it.
Signed-off-by: Aaron Ma <mapengyu@gmail.com>
Reviewed-by: Marco Giunta <marco_giunta@outlook.it>
Tested-by: Marco Giunta <marco_giunta@outlook.it>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260804185325.22861-1-mapengyu@gmail.com
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->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->bInterfaceNumber,
step0_resp, private->step0_resp_size);
if (err < 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 < 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 <baul.lee@xbow.com>
Fixes: 46757a3e7d ("ALSA: FCP: Add Focusrite Control Protocol driver")
Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
Reported-by: Baul Lee <baul.lee@xbow.com>
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee <baul.lee@xbow.com>
Link: https://patch.msgid.link/20260805013804.38839-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
bcd2000_free_usb_related_resources() frees both URBs and leaves the
pointers behind:
usb_kill_urb(bcd2k->midi_out_urb);
usb_kill_urb(bcd2k->midi_in_urb);
usb_free_urb(bcd2k->midi_out_urb);
usb_free_urb(bcd2k->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->midi_out_urb->transfer_buffer_length = BUFSIZE;
...
ret = usb_submit_urb(bcd2k->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 <baul.lee@xbow.com>
Fixes: b47a22290d ("ALSA: MIDI driver for Behringer BCD2000 USB device")
Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
Reported-by: Baul Lee <baul.lee@xbow.com>
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee <baul.lee@xbow.com>
Link: https://patch.msgid.link/20260805013428.38204-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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->status) {
if (rt->receiver_buffer[0] == 0x10) /* midi in event */
if (midi_rt)
midi_rt->in_received(midi_rt,
rt->receiver_buffer + 2,
rt->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->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->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 <baul.lee@xbow.com>
Fixes: c6d43ba816 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB")
Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
Reported-by: Baul Lee <baul.lee@xbow.com>
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee <baul.lee@xbow.com>
Link: https://patch.msgid.link/20260805013423.38175-1-baul.lee@xbow.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
