linux-stable.git/sound, branch v7.2.4 Linux kernel stable tree ALSA: hda/realtek: Fix Lenovo Yoga Slim 7 14AKP10 quirk ordering 2026-09-07T15:37:22+00:00 Zhang Heng zhangheng@kylinos.cn 2026-08-17T09:47:08+00:00 641dacada33127948850bd31e50bbe9d5e84a4d2 commit 75dc2eda659f6be4a370734f11baf25df8a9fd80 upstream. The Yoga Slim 7 14AKP10 has a PCI SSID of 17aa:38b4 but a codec SSID of 17aa:391a. The current quirk table contains a PCI quirk for 17aa:38b4 (for the Legion Slim 7 16IRH8) which matches first, so the codec-specific quirk for 17aa:391a is never applied. This results in the wrong fixup being used (CS35L41_I2C_2 instead of the correct bass speaker fixup), leaving the internal speakers misconfigured or silent. Remove the 17aa:391a entry from its PCI-SSID-sorted position and add it as an HDA_CODEC_QUIRK directly before the 17aa:38b4 entry, because it must match on the codec subsystem ID rather than the PCI SSID and it has to win over the colliding PCI quirk for the Legion Slim 7 16IRH8. A comment is added to explain the out-of-order placement, following the same style already used for the 17aa:38bb and 17aa:38f9 codec-SSID overrides. With this change, the correct ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN is applied, restoring speaker output and auto-mute functionality. The original quirk added in commit e6c888202297 ("ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 7 14AKP10") matched on the PCI SSID 17aa:391a, but this model actually exposes PCI SSID 17aa:38b4 (shared with the Legion Slim 7 16IRH8), so that quirk never matched and the bass speaker remained silent. Fix it by matching on the codec SSID and placing the entry before the colliding 17aa:38b4 PCI quirk. Fixes: e6c888202297 ("ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 7 14AKP10") Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=221298 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260817094708.222154-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 75dc2eda659f6be4a370734f11baf25df8a9fd80 upstream.

The Yoga Slim 7 14AKP10 has a PCI SSID of 17aa:38b4 but a codec SSID of
17aa:391a. The current quirk table contains a PCI quirk for 17aa:38b4
(for the Legion Slim 7 16IRH8) which matches first, so the codec-specific
quirk for 17aa:391a is never applied.

This results in the wrong fixup being used (CS35L41_I2C_2 instead of the
correct bass speaker fixup), leaving the internal speakers misconfigured
or silent.

Remove the 17aa:391a entry from its PCI-SSID-sorted position and add it as
an HDA_CODEC_QUIRK directly before the 17aa:38b4 entry, because it must
match on the codec subsystem ID rather than the PCI SSID and it has to win
over the colliding PCI quirk for the Legion Slim 7 16IRH8.  A comment is
added to explain the out-of-order placement, following the same style
already used for the 17aa:38bb and 17aa:38f9 codec-SSID overrides.

With this change, the correct ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN is
applied, restoring speaker output and auto-mute functionality.

The original quirk added in commit e6c888202297 ("ALSA: hda/realtek: Add
quirk for Lenovo Yoga Slim 7 14AKP10") matched on the PCI SSID 17aa:391a,
but this model actually exposes PCI SSID 17aa:38b4 (shared with the Legion
Slim 7 16IRH8), so that quirk never matched and the bass speaker remained
silent.  Fix it by matching on the codec SSID and placing the entry before
the colliding 17aa:38b4 PCI quirk.

Fixes: e6c888202297 ("ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 7 14AKP10")
Cc: stable@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221298
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260817094708.222154-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda/realtek: Enable micmute LED on HP EliteBook 6 G1a p/n: AD3Q9ET#UUG 2026-09-07T15:37:22+00:00 Denis Batishchev ii343hbka@gmail.com 2026-08-10T15:14:41+00:00 2bfc88e83398313f78983aadecaaf92d732f4d25 commit e7da28b820d12927de30abf554c727a319f80359 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e7da28b820d12927de30abf554c727a319f80359 upstream.

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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda/realtek: Enable headset mic on F+ FLAPTOP r 2026-09-07T15:37:22+00:00 Ajrat Makhmutov rauty@altlinux.org 2026-08-08T18:55:00+00:00 013daf7193702ebc61b8f3537065aa735d181e98 commit 7097666b993b37f4e47982026b703b2379a364f8 upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7097666b993b37f4e47982026b703b2379a364f8 upstream.

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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx 2026-09-07T15:37:22+00:00 Eckhart Mohr e.mohr@tuxedocomputers.com 2026-08-21T14:44:34+00:00 17fc26d7bbe8ae8e4dd3ba714807a9e5ad870be9 commit e72d5659a2606056a0c34af212b46a3275a55bbf upstream. Fix microphone detection on built in headphone jack for some devices Signed-off-by: Eckhart Mohr <e.mohr@tuxedocomputers.com> Cc: stable@vger.kernel.org Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Link: https://patch.msgid.link/20260821144437.27233-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e72d5659a2606056a0c34af212b46a3275a55bbf upstream.

Fix microphone detection on built in headphone jack for some devices

Signed-off-by: Eckhart Mohr <e.mohr@tuxedocomputers.com>
Cc: stable@vger.kernel.org
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Link: https://patch.msgid.link/20260821144437.27233-1-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: virmidi: Check card index validity at probe 2026-09-07T15:37:22+00:00 Takashi Iwai tiwai@suse.de 2026-08-06T15:32:21+00:00 f48c5f3b03afdb795e5f448a1d53d912d5b09f2e commit b65d5182ecd6b7a24a83d980a0d06e809ef876c5 upstream. 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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b65d5182ecd6b7a24a83d980a0d06e809ef876c5 upstream.

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
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: serial-u16550: Check card index validity at probe 2026-09-07T15:37:22+00:00 Takashi Iwai tiwai@suse.de 2026-08-06T15:32:20+00:00 6d6fdb24fe2eaf6174fc502284c6e1dc5f7242ba commit e0fb960b227fcdebe22e4f26c9486d60943c0424 upstream. 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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e0fb960b227fcdebe22e4f26c9486d60943c0424 upstream.

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
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: portman2x4: Check card index validity at probe 2026-09-07T15:37:22+00:00 Takashi Iwai tiwai@suse.de 2026-08-06T15:32:23+00:00 e1ce8ad1009b1736b3044b3324350dcfdd516f42 commit 3690ef20469d5959378260e2752f2314a2572913 upstream. 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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3690ef20469d5959378260e2752f2314a2572913 upstream.

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
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: pcxhr: initialize mutexes before requesting threaded IRQ 2026-09-07T15:37:22+00:00 Runyu Xiao runyu.xiao@seu.edu.cn 2026-08-18T14:47:17+00:00 7cf280fbef5db6310e1b32074c8c34d1ba459796 commit 6c97817e20598e5473094e0e38d1f51f1cf4dfff upstream. pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe. Fixes: 9bef72bdb26e ("ALSA: pcxhr: Use nonatomic PCM ops") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Link: https://patch.msgid.link/20260818144717.2269918-1-runyu.xiao@seu.edu.cn Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6c97817e20598e5473094e0e38d1f51f1cf4dfff upstream.

pcxhr_probe() requests pcxhr_threaded_irq() before initializing
mgr->lock, even though the threaded handler takes that mutex.

Initialize the manager locks before request_threaded_irq() so an
early interrupt cannot run against uninitialized mutex state during
probe.

Fixes: 9bef72bdb26e ("ALSA: pcxhr: Use nonatomic PCM ops")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://patch.msgid.link/20260818144717.2269918-1-runyu.xiao@seu.edu.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: mts64: Check card index validity at probe 2026-09-07T15:37:22+00:00 Takashi Iwai tiwai@suse.de 2026-08-06T15:32:22+00:00 cf3af453a48c8d905512dfc44a5a59439b70f4f0 commit d18a260720f86a5f8b5fcfefc4ba2e9dd01c10f8 upstream. 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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d18a260720f86a5f8b5fcfefc4ba2e9dd01c10f8 upstream.

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
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: mpu401: Check card index validity at probe 2026-09-07T15:37:22+00:00 Takashi Iwai tiwai@suse.de 2026-08-06T15:32:19+00:00 8adda66edf795d4648f8e26f312e4414c535d25a commit f7dcecb92ed192ff5fcf842918fb1aaea84b5bdd upstream. 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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f7dcecb92ed192ff5fcf842918fb1aaea84b5bdd upstream.

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
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>