| Age | Commit message (Collapse) | Author |
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.3
A fairly small collection of fixes and a few device quirks, nothing
especially remarkable unless you have the affected system.
|
|
This adds the following SoundWire configuration:
cs42l43b link 0 UID 1
cs35l57 link 0 UID 0
cs35l57 link 0 UID 1
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Link: https://patch.msgid.link/20261007130857.102432-1-simont@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
A BIOS for this SKU has been observed with an incorrect
acp-audio-config-flag, add the override so that it is forced to the
correct value.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Link: https://patch.msgid.link/20261007130835.102325-1-simont@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Richard Fitzgerald <rf@opensource.cirrus.com> says:
The amp feedback path (AEC) was incorrectly using SoundWire DP3.
The firmware outputs SDCA OT25 feedback on DP4. DP3 is reserved for
SDCA companion amp.
This series adds a DAI for OT25 and switches the sdw machine driver
to use the new DAI for the feedback path.
Link: https://patch.msgid.link/20261005155235.1386525-1-rf@opensource.cirrus.com
|
|
Change the CS35L56/57/62/63 entries in codec_info_list[] to use
the OT25 DAI for amp feedback.
The AMP feedback was incorrectly using a DAI connected to DP3,
but that is reserved for SDCA companion amp. The correct amp
output is DP4, which is the SDCA OT25 feedback output.
Fixes: 898cd43bde307 ("ASoC: intel: sof_sdw: Add support for CS35L63 into machine driver")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20261005155235.1386525-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add a DAI for the SDCA OT25 stream on SoundWire DP4.
The SDCA-defined OT25 stream is an amp reference feedback, typically used
for AEC. The firmware outputs this on DP4. The firmware owns all control
registers for this stream so there are no mixer controls or any other
configuration options.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20261005155235.1386525-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The probe function puts the device into the runtime PM active state with
only the "iis" bus clock enabled, but it also sets priv->op_clk to the
parent of the RCLK_SRC mux without enabling it. The runtime PM suspend
callback disables both clocks, so the first runtime suspend after probe
disables op_clk once more than it was enabled.
On Exynos5250 Arndale both clocks resolve to the same EXYNOS_I2S_BUS gate,
so this triggers the following warning during boot:
WARNING: drivers/clk/clk.c:1270 at clk_core_disable+0xe4/0x23c, CPU#0: kworker/u8:3/45
i2s_bus already disabled
...
Workqueue: pm pm_runtime_work
Call trace:
...
clk_core_disable from clk_disable+0x28/0x34
clk_disable from i2s_runtime_suspend+0x58/0x68 [snd_soc_i2s]
i2s_runtime_suspend [snd_soc_i2s] from genpd_runtime_suspend+0xc4/0x298
genpd_runtime_suspend from __rpm_callback+0x48/0x18c
__rpm_callback from rpm_callback+0x4c/0x50
rpm_callback from rpm_suspend+0xf4/0x718
rpm_suspend from pm_runtime_work+0x9c/0xa0
...
Fix this by enabling op_clk in probe right after getting it, so the clock
state matches the runtime PM active state, and by disabling it in remove.
Fixes: 48279c53fd1d ("ASoC: samsung: i2s: Prevent external abort on exynos5433 I2S1 access")
Assisted-by: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://patch.msgid.link/20261002092116.585466-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The chip has strange power-on reset values for the registers that
control the output ASRC and DAC source muxes - the values are actually
marked "Reserved" in the datasheet [1]. This means that until the
underlying kcontrols are modified, the codec will not function as
expected.
The registers in question are:
register / field reset value valid values
ASRCO_SOURCE_0_1 0x10
ASRC_OUT_SOURCE0 0 4 .. 16
ASRC_OUT_SOURCE1 1 4 .. 16
ASRCO_SOURCE_2_3 0x10
ASRC_OUT_SOURCE2 2 4 .. 16
ASRC_OUT_SOURCE3 3 4 .. 16
DAC_SOURCE_0_1 0x10
DAC_SOURCE_0 0 12 .. 13
DAC_SOURCE_1 1 12 .. 13
Set some sane defaults during the driver probe:
ADC Decimator0 -> Output ASRC0
ADC Decimator1 -> Output ASRC1
ADC Decimator2 -> Output ASRC2
ADC Decimator3 -> Output ASRC3
Input ASRC0 -> DAC0
Input ASRC1 -> DAC1
With this, the chip will behave as advertised by the default kcontrol
state exposed by the driver.
[1] https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1372.pdf
Fixes: 6cd4c6459e47 ("ASoC: Add ADAU1372 audio CODEC support")
Signed-off-by: Alvin Šipraga <alvin.sipraga@analog.com>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20261006-asoc-adau1372-fixes-v1-2-599cc17fb5f6@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
gpiod_set_value() emits a WARN when the GPIO provider indicates that it
can sleep, as is typical for I2C controlled GPIO expanders. Since the
powerdown GPIO is only manipulated in process context, use the _cansleep
variant instead. This lets the driver use sleepy GPIOs to power off the
chip.
Fixes: 6cd4c6459e47 ("ASoC: Add ADAU1372 audio CODEC support")
Signed-off-by: Alvin Šipraga <alvin.sipraga@analog.com>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20261006-asoc-adau1372-fixes-v1-1-599cc17fb5f6@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The Acer Aspire Go 15 (AG15-21P, board MDC Herbag2_MDU) has two PDM
DMICs connected to the ACP. The BIOS does not set the AcpDmicConnected
_DSD property, so the acp6x machine driver never registers the DMIC
card. The existing Herbag_MDU entry does not match this board name, so
add a DMI quirk for it.
Tested on BIOS V1.11: the acp6x DMIC capture device is registered and
records audio on both channels.
Cc: stable@vger.kernel.org
Signed-off-by: Michael Garland <minimelkav@gmail.com>
Link: https://patch.msgid.link/20261005-acp6x-herbag2-quirk-v1-1-a1f2683d758f@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The mute LED on the HP Pavilion Laptop 15-eg3xxx (PCI SSID 103c:8bfd,
Realtek ALC287) does not work because the machine has no entry in the
quirk table. No fixup is applied, so the mute LED is never driven, even
though the mute function itself works.
The LED is controlled via GPIO pin 4 (mask 0x10), which is exactly what
ALC287_FIXUP_HP_GPIO_LED configures. This was verified on the hardware
with hda-verb: setting the GPIO data bit lights the mute LED, and
clearing it turns the LED off.
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x10
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIRECTION 0x10
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x10 # LED on
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x00 # LED off
Add a quirk entry for 103c:8bfd using ALC287_FIXUP_HP_GPIO_LED.
Signed-off-by: Jaidheer Sirigineedi <jaidheer7@gmail.com>
Link: https://patch.msgid.link/20261002185951.33855-1-jaidheer7@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Some Lenovo BIOSes (e.g. Legion Pro 7 16IRX9H, SSID 17aa:38cd) store
valid V1 calibration data in the CALI_DATA EFI variable but leave the
TimeStamp and CRC fields zeroed. The driver rejects such data, so the
amplifiers always run with default parameters on these machines.
The rejection was silent until
commit 4fe238513407 ("ALSA: hda/tas2781: Move and unified the
calibrated-data getting function for SPI and I2C into the tas2781_hda lib")
turned it into "V1 CRC error".
The stored values are consistent (R0 = 3.82/3.83 ohm, 1/R0 matching
within 1e-4), so accept V1 data when both TimeStamp and CRC are zero
and the first device entry is non-zero, and emit a warning.
Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
Cc: stable@vger.kernel.org
Signed-off-by: Mohamed Yassine Jebabli <med.jebabli@gmail.com>
Link: https://patch.msgid.link/20261001-tas2781-v1-nocrc-v1-1-ff0c1032ce76@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Commit e576e7843c0d ("ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions")
centralized the DAO input mapper clearing logic in
dao_clear_input(), but omitted the kfree() calls.
It removes the mapper entries from the list and sets their pointers
to NULL without freeing the allocated array. This leaks memory each
time dao_clear_input() is called.
Store the base pointer of the allocation before clearing the mapper
entries and free the array after removing entries from the list.
Fixes: e576e7843c0d ("ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions")
Cc: stable@vger.kernel.org
Signed-off-by: Harin Lee <me@harin.net>
Link: https://patch.msgid.link/20261001144501.3050667-2-me@harin.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Fix headphone jack detection for some devices
Signed-off-by: Eckhart Mohr <e.mohr@tuxedocomputers.com>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Link: https://patch.msgid.link/20261001183403.103990-1-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Cambridge Audio streamer advertises the UAC2 RAW_DATA format on
altsetting 2 of its playback interface, but without the DSD_RAW quirk
flag the driver exposes it only as a SPECIAL format that cannot be
used.
Add QUIRK_FLAG_DSD_RAW for the device (USB ID 22e8:ca10), so the
altsetting is exposed as DSD_U32_BE, enabling native DSD64/128/256
playback.
Tested with: gst-launch-1.0 filesrc location=file.dsf ! \
avdemux_dsf ! dsdconvert ! \
alsasink device=hw:2,0
Signed-off-by: Matus Gajdos <matuszpd@gmail.com>
Link: https://patch.msgid.link/20261002125237.82188-1-matuszpd@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.3
A bigger collection of fixes than usual due to your vacation but nothing
hugely remarkable here, just fairly standard quirks and driver specific
bugfixes.
|
|
We used the auto-cleanup via snd_card_unref() for errors at probe of
ice1712 driver, but this may be problematic in a subtle way when an
error happens at snd_card_register(); since snd_card_unref() skips the
snd_card_disconnect() call, it may miss some resource clearance.
For fixing the issue, use the new __free(snd_card_free) instead, which
does call snd_card_free() explicitly at errors for avoiding such a
pitfall.
Fixes: d736eba9c453 ("ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup")
Link: https://patch.msgid.link/20261001151039.592033-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The ALC235 (0x10ec0235) is registered as the ALC255 codec variant in
patch_alc269(), but the headset mode functions were missing a case
for it, so the CTIA/OMTP jack type detection and routing never ran
on this codec. As a result, a plugged-in headset is detected (jack
presence works) but the microphone signal is never routed, leaving
the capture stream permanently silent.
Verified on an ASUS M5451GA laptop (HDA:10ec0235,10431814): with the
ALC255 coef sequence applied, the headset microphone works correctly.
Signed-off-by: Zeyu Li <13776528859@163.com>
Link: https://patch.msgid.link/20260926140336.27896-1-13776528859@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Acer Swift SFG16-72 (1025:173b) uses the ALC245 codec, but its
mic-mute LED is not enabled by default. Apply the existing
ALC245_FIXUP_ACER_MICMUTE_LED quirk to enable the mic-mute LED.
Assisted-by: LLM
Cc: stable@vger.kernel.org
Signed-off-by: Jakub Gawlik <jakubgawlik13@gmail.com>
Link: https://patch.msgid.link/20260930145839.374762-1-jakubgawlik13@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP ENVY x360 2-in-1 Laptop 15-ey0xxx (SSID 103c:8a31, ALC245 with
CS35L41 I2C amps) currently only gets ALC287_FIXUP_CS35L41_I2C_2, so the
mute and micmute LEDs on the keyboard never light up.
On this machine the mute LED is driven by COEF 0x0b bits 2-3 and the
micmute LED by GPIO 0x04 (active low), which is exactly what
ALC245_FIXUP_HP_X360_MUTE_LEDS sets up. Switch the quirk to
ALC287_FIXUP_CS35L41_I2C_2_HP_MUTE_LEDS, which keeps the CS35L41 setup
and chains to that LED fixup.
Verified by driving the COEF and GPIO values by hand with hda-verb,
following Master Playback Switch and Mic ACP LED Capture Switch.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Harrison Lucas <tiiowsalt@gmail.com>
Link: https://patch.msgid.link/20260929174348.167537-1-tiiowsalt@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP Pavilion 14-dv1001TU (subsystem ID 103c:8987) uses a Realtek
ALC287 codec. The mute LED on this machine is controlled by GPIO bit
0x10, which was verified via hda-verb, but the subsystem ID is missing
from the quirk table. As a result, the ALC287_FIXUP_HP_GPIO_LED fixup
that drives GPIO 0x10 is never applied and the mute LED stays off even
though the associated LED class device toggles correctly.
Add the missing SND_PCI_QUIRK entry to map this subsystem ID to
ALC287_FIXUP_HP_GPIO_LED so the mute LED works as expected.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221810
Signed-off-by: renpanpan <renpanpan@kylinos.cn>
Link: https://patch.msgid.link/20260930065504.24151-1-rppxj178543@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Commit 4b490e0d103c ("ALSA: ctxfi: Add ADC helper functions for GPIO")
moved the GPIO_DATA read into hw_adc_stop(), but the Titanium HD
(SB1270) setup in hw_adc_init() uses the local data variable holding
the GPIO_CTRL value.
Writing this value to GPIO_DATA sets the output mute bits. Playback
runs without errors, but the outputs stay muted.
Re-read GPIO_DATA before setting the speed mode bits. Also, add the
delay after writing the mode bits, as in the original sequence.
On affected kernels, switching the output selection was reported to
restore clean playback.
Fixes: 4b490e0d103c ("ALSA: ctxfi: Add ADC helper functions for GPIO")
Cc: stable@vger.kernel.org
Reported-by: Dany Patoine <dany_patoine@hotmail.com>
Closes: https://lore.kernel.org/linux-sound/DM6PR02MB5433A42E81FEFAC400DD1905EA8B2@DM6PR02MB5433.namprd02.prod.outlook.com/
Signed-off-by: Harin Lee <me@harin.net>
Link: https://patch.msgid.link/20260930115824.739412-1-me@harin.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Faaris reported a problem with Audient EVO4 device and it turned out
to be a regression by the recent fix commit 87a6f2fa6e6c ("ALSA:
usb-audio: Propagate write errors in generic mixer put callbacks").
It exhibited that the hardware gives errors at accessing the mixer
unit 10 on certain channels, and the change above made it a fatal
error.
We had already a quirk for Audient iD14 to work around such errors
from the mixer controls, and we can simply apply the same for EVO4.
OTOH, it's highly possible that other Audient devices suffer from the
same issue; they must be using similar firmware, after all.
So, in this patch, we apply the quirk generically to all devices with
the vendor ID Audient (2708), instead. Ignoring the control error
isn't usually less critical than overreaction to the firmware
misbehavior.
Fixes: 87a6f2fa6e6c ("ALSA: usb-audio: Propagate write errors in generic mixer put callbacks")
Reported-and-tested-by: Faaris Ansari <faarisansari@googlemail.com>
Closes: https://lore.kernel.org/CANBVYRCL=8QdLxGg4S6qrahrFtwJxhv-aSGpW7-1S=+iOe4ZGA@mail.gmail.com
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260929144132.1521617-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Jan reported that a few Behringer devices became broken since the
recent optimization to avoid usb_string() call at probe time at the
commit b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev
for manufacturer & co"). Interestingly, the devices seem requiring
the explicit descriptor read at probing time, and the optimization
above dropped it.
There is already a boot quirk for another model, Behringer CM1A
(1397:1234), that adds a device descriptor read, and this seems
working for them, too. As the quirk is safe and cheap, just apply the
same boot quirk to all Behringer devices for avoiding the pitfall
again.
Fixes: b364a0d23cae ("ALSA: usb-audio: Use strings in struct usb_dev for manufacturer & co")
Reported-by: Jan Lentfer <jan.lentfer@web.de>
Closes: https://lore.kernel.org/e7087d42-5e74-4d85-b1c5-b11eff235d41@web.de
Link: https://patch.msgid.link/20260929122938.1471867-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
enabling clocks
Commit 902f497a1ff5 ("ASoC: codecs: lpass-wsa-macro: remove useless
gain read/write sequence") removed the read and write of the digital
volume register in wsa_macro_enable_interpolator(), on the grounds that
writing back the value just read does nothing. The comment above it,
"apply gain after int clk is enabled", was left in place.
On the Dell XPS 13 9345 (X1E80100, four WSA8845 amplifiers on two WSA
macros) the write does something: a volume change made while the path
is idle does not take effect when playback starts. Lowering the digital
volume from 81 to 63 with nothing playing, then playing a test tone,
gave about the same level as before the change. With the rewrite
restored, lowering it from 81 to 69 while idle played audibly quieter,
and restoring 81 while idle brought the level back. Changes made during
playback take effect with or without the rewrite.
The register already holds the new value when this happens. Without the
rewrite, after an idle change from 69 to 81, playback stayed at the old
level while the register, read from the hardware through /dev/mem, held
the new one (0xfd). Writing that same value back through /dev/mem
brought the level up at once.
This is the behaviour described in commit 46188db080bd ("ASoC: codecs:
lpass-wsa-macro: fix compander volume hack"): "the volume registers
still need to be written after enabling clocks in order for any prior
updates to take effect." The value read comes from the register cache,
so the write pushes the last requested volume to the hardware once its
clock runs.
Restore the rewrite in the interpolator's POST_PMU event only. The mix
path event removed later in the same series is not brought back.
Fixes: 902f497a1ff5 ("ASoC: codecs: lpass-wsa-macro: remove useless gain read/write sequence")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Liviu Nicoara <lnicoara@thinkoid.org>
Reviewed-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260929115755.6096-1-lnicoara@thinkoid.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ASUS ExpertBook PM3406CHA uses an ALC256 codec with subsystem
ID 1043:1664. On Linux boot, the internal speakers are silent even
though playback is routed to the codec and the speaker pin is
configured for output.
The codec starts with coefficient 0x10 set to 0x1d20. Writing 0x7f20
to coefficient 0x10 immediately restores internal speaker output.
This was reproduced on the affected hardware from a fresh boot using
hda-verb. Reducing a larger initialization sequence showed that this
coefficient write alone is sufficient; no GPIO, EAPD, pin-control, or
other coefficient changes are required. After applying the coefficient
in userspace, speaker output also remains functional across suspend
and resume.
Add a machine-specific HDA fixup that writes the required coefficient.
The fixup has been compile-tested, but could not be boot-tested because
the affected hardware is no longer available.
Closes: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2162718
Signed-off-by: Muhtasham Nawr al-Mahmud <muhtaseem2005@gmail.com>
Link: https://patch.msgid.link/20260924144512.3989-1-muhtaseem2005@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add ALC225_FIXUP_HP_AIO_SPK to enable the internal speaker on
HP Pavilion AiO 24 (103c:85ba).
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221691
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260929091109.400313-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP Laptop 15-fd2xxx (PCI SSID 103c:8e43, Realtek ALC236) has a
speaker mute LED on the F5 key and a microphone mute LED on the F8 key.
Neither lights up, because the model has no quirk entry and only the
generic HP vendor fallback (ALC269_FIXUP_HP_MUTE_LED) is applied.
Probing the codec with hda-verb showed how the LEDs are wired:
- mute LED: COEF index 0x07, bit 0, on NID 0x20 (set = LED on)
- mic mute LED: codec GPIO0, active low (driven low = LED on)
Driving GPIO1 and GPIO2 did not light the mute LED. This wiring is
exactly what the existing ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO fixup
implements (COEF 0x07 bit 0 for the mute LED, GPIO0 with inverted
polarity for the micmute LED), so use it for this model. The sibling
HP Laptop 15-fd0xxx (103c:8dd7) already uses the same fixup.
Tested on this machine running Ubuntu 7.0.0-34-generic (SOF driver, the
quirk built into snd-hda-codec-alc269 from Ubuntu's 7.0.0-34.34 source
tree): the hda::mute and hda::micmute LEDs are created, follow the
Master mute state and the Dmic0 capture switch respectively, and the
F5 and F8 keys toggle them correctly. Muting the microphone also
silences the capture stream. The LEDs also kept the correct state across
an s2idle suspend/resume cycle (speaker muted in one run, microphone in
another) and still responded to mute changes afterwards; long suspends
were not tested. The desktop session was SwayFX (wlroots) with PipeWire,
which only changes the mute state through the normal mixer controls; no
other desktop was tried. Not tested on a mainline kernel tree directly;
the change is only the quirk table entry.
AI assistance: this patch, the hardware analysis behind it (probing the
codec with hda-verb and choosing the existing fixup) and this commit
message were written by Claude Code (Anthropic, model claude-sonnet-5-5).
The submitter ran the privileged commands and reboots and reported the
LED behavior; Claude Code ran the tests and read the kernel logs.
Assisted-by: Claude:claude-sonnet-5-5
Signed-off-by: Preston Lam <plamlam99@gmail.com>
Link: https://patch.msgid.link/20260928231621.1672704-1-plamlam99@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add ASUS Zenbook S14 UM5406GA (Strix Point, ACP 7.0) to
acp70_acpi_flag_override_table so that the broken BIOS
acp-audio-config-flag is ignored and the default SoundWire
enumeration path is used. Without this, no ASoC machine driver
matches and internal speakers/mic fail to probe.
Reported-by: Jannick Tobler <business@jtobler.net>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222009
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260928083925.266471-1-zhangheng@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Laptop 15-dw1xxx
The HP Pavilion 15-eh3174nw with an ALC287 codec requires the
ALC287_FIXUP_HP_GPIO_LED fixup for its mute LED to work correctly.
Add subsystem ID 0x103c:0x8bc7 to the quirk table to apply the
existing fixup.
Tested on an HP Pavilion 15-eh3174nw; the mute LED now follows the
speaker mute state.
The HP Laptop 15-dw1xxx with an ALC236 codec requires the
ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO fixup for its mute LED to work correctly.
Add subsystem ID 0x103c:0x85f1 to the quirk table to apply the existing fixup.
Tested on an HP Laptop 15-dw1xxx; the mute LED now follows the speaker
mute state.
Signed-off-by: Bartosz Brom <bartosz.brom06@gmail.com>
Link: https://patch.msgid.link/20260928134335.1875-1-bartosz.brom06@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
A variant of the Lenovo Yoga Slim 7 exists on Lunar Lake that
doesn't have a physical jack socket. Cirrus codecs still use match
tables on LNL but the match table makes no distinction between a system
with or without a jack. This leads to the system failing probe as the
jack in the topology file is not matched by a DAI link as the machine
driver is constructed.
Add a new quirk to block using match tables for specific devices, and
rely on function topologies which can handle this difference seamlessly.
This is slightly preferred over moving everything to function topologies
due to the lower chance of causing regressions on other systems.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260928105610.242687-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The HP Victus 15-fb2xxx (PCI SSID 103c:8c2f) with the ALC245 codec
does not turn on the mute LED when audio is muted.
Add a quirk entry to enable it.
Reported-by: erph.briones27@gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221946
Signed-off-by: Krish Gulati <krishgulati7@gmail.com>
Tested-by: Raphael Briones <erph.briones27@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260921131728.8999-1-krishgulati7@gmail.com
|
|
The Acer Nitro AN515-45 requires ALC2XX_FIXUP_HEADSET_MIC to make the
headset microphone work properly.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221925
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260921124450.639601-2-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Fix Bass Speaker volume control on Lenovo ThinkBook G8+ by adding
quirk 17aa:38dc with ALC285_FIXUP_SPEAKER2_TO_DAC1.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221799
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260921124450.639601-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It lost its headset microphone functionality, and this patch will restore it.
Fixes: 97272a5704bf ("ALSA: hda/realtek - Fixed Headphone noise issue for Dell QCM1255")
Signed-off-by: Kailang Yang <kailang@realtek.com>
Link: https://lore.kernel.org/3c251e40a2944ae4ae479e4c2e4e63a4@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This workaround was originally added for Tegra194, but no longer gets
applied for it. Commit 615d43540043 ("ALSA: hda/tegra: fix tegra-hda on
tegra30 soc") changed the guard to tegra30-hda, which worked because all
affected archs had the fallback compatible. However, commit 7f0ea5acfc19
("arm64: tegra: Use correct compatible string for Tegra194 HDA") removed
the fallback compatible for Tegra194, causing this to break.
Fixes: 7f0ea5acfc19 ("arm64: tegra: Use correct compatible string for Tegra194 HDA")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Link: https://patch.msgid.link/20260926-tegra194-hda-sdo-v1-1-f7a636a07a58@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The DAI ID is a hardware port ID and is not necessarily the index of
the corresponding entry in variant->dai_driver.
When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code
currently uses dai_id to index variant->dai_driver. This is incorrect
for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S
DAI has ID 4 while it is the only entry in the DAI driver table. If
that DAI is configured for QUAD01 and probe reaches this branch, the
code writes beyond that single entry via dai_driver[4] instead of
updating the DAI being processed.
Use the loop index i when updating the current DAI's playback channel
constraints, while retaining dai_id for indexing the hardware-port
specific playback SD-line mode array.
This fixes the incorrect DAI table access for platforms where the DAI
ID does not match its position in the driver table.
Fixes: c223f41c1a52 ("ASoC: qcom: Add four speaker support on MI2S secondary")
Cc: stable@vger.kernel.org
Signed-off-by: Zimeng Li <me@lizi.moe>
Assisted-by: LLM-assisted source analysis
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260927010911.51980-1-me@lizi.moe
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
setup_card() registers the input device, whose name and phys point into
struct snd_usb_caiaqdev, and then goes on to snd_card_register() and
snd_usb_caiaq_control_init(). If either fails, snd_probe() calls
snd_card_free(), which frees the device state but leaves the input
device registered: card_free() only clears the pointer, and the input
device is unregistered from snd_disconnect() alone. Reading its "uevent"
attribute afterwards dereferences freed memory:
BUG: KASAN: slab-use-after-free in string+0x4a9/0x4f0
Read of size 1 at addr ffff8880208f5043 by task caiaq/4967
add_uevent_var+0x183/0x3a0
input_dev_uevent+0x162/0x900
dev_uevent+0x2f1/0x870
uevent_show+0x1ca/0x3a0
...
Unregister the input device on the probe error path, as
snd_disconnect() does. snd_usb_caiaq_input_disconnect() is a no-op when
no input device was registered.
Reproduced with a raw-gadget Audio Kontrol 1 and a temporary hack that
makes snd_usb_caiaq_control_init() fail.
Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly")
Cc: stable@vger.kernel.org
Reported-by: syzbot+2a123f6269da57ffefaa@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=2a123f6269da57ffefaa
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Link: https://patch.msgid.link/20260925170717.22462-1-ngocthang2710.1999@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The USB audio device 0db0:cc78 (Realtek ALC4080) on the MSI MAG B850M
MORTAR WIFI motherboard exposes all playback controls as "PCM", which
makes it hard to tell the outputs apart.
Its mixer layout matches the one of the MSI MPG X570S Carbon Max Wifi
(units 29, 30 and 32), so reuse msi_mpg_x570s_carbon_max_wifi_alc4080_map
for this device too. With the mapping applied, the controls show up as
"Speaker", "Front Headphone" and "IEC958".
Tested with a patched snd-usb-audio module on a 7.2.7 kernel.
Signed-off-by: Tomasz Bojanowski <tomasz@bojanowski.me>
Link: https://patch.msgid.link/20260923184957.6687-1-tomasz@bojanowski.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Higole F9B is an Alder Lake-N mini PC with a 7" touchscreen and an
ALC269VC codec (subsystem ID 0x10ec111e). Its DMI strings are all
"Default string", so the SSID is the only way to identify it.
The internal speaker is silent out of the box. The generic parser
assigns DAC 0x03 to the speaker pin 0x14 and DAC 0x02 to the headphone
pin 0x15, but the speaker only reproduces what DAC 0x02 plays, whatever
its connection selection says. Checked one path at a time, only the
gain of DAC 0x02 and the mute of pin 0x14 change what comes out of the
speaker. User space only knows the path it was told the speaker uses,
so selecting the speaker turns the path that actually reaches it all
the way down.
Route both 0x14 and 0x15 through mixer 0x0c (DAC 0x02), which is what
ALC290_FIXUP_MONO_SPEAKERS already does. Tested on the device: the
speaker plays.
Cc: <stable@vger.kernel.org>
Assisted-by: LLM
Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com>
Link: https://patch.msgid.link/20260923141344.1543158-1-asas1asas200@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ASUS ROG Strix G16 G615LR (PCI SSID 1043:3f20) outputs a loud
full-scale square wave from internal speakers since the TAS2781
amplifier driver started loading. The quirk was using
ALC287_FIXUP_TXNW2781_I2C which chains to the ThinkPad headset
jack fixup, but this is an ASUS device that should use
ALC287_FIXUP_TXNW2781_I2C_ASUS which chains to ALC294_FIXUP_ASUS_SPK
for proper EAPD and pin configuration.
Fixes: f7cede182c96 ("ALSA: hda/realtek: Add Asus quirk for TAS amplifiers")
Cc: stable@vger.kernel.org
Cc: Baojun Xu <baojun.xu@ti.com>
Cc: Antheas Kapenekakis <lkml@antheas.dev>
Reported-by: Aleksei Arsenev <alesharik4@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=222045
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260923121640.272509-1-zhangheng@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP ENVY Laptop 13-aq1xxx (PCI SSID 103c:86ad) uses an ALC285 codec
with two speaker pairs: front (pin 0x14) and bottom (pin 0x17).
The BIOS leaves pin 0x14 as [N/A] ("not connected"), so the generic
parser never enables the front pair and only the bottom speakers are
audible. The vendor driver (RTKVHD64.sys) programs that pin with the
value 0x90170150 and runs the HP amplifier initialization, which is
already implemented in the driver as ALC285_FIXUP_HP_GPIO_AMP_INIT.
Add a board fixup that applies the pin configuration for 0x14 and chains
to the existing amplifier init fixup.
The pin value was recovered from the vendor driver's own configuration
data. The patch and this changelog were prepared with an AI coding
assistant (see the Assisted-by tag below); the change was reviewed and
tested by the submitter on the affected machine.
Tested on an HP ENVY 13-aq1xxx by rebuilding snd-hda-codec-alc269 from
the Fedora 7.1.10 source and loading it: the codec now reports
"line_outs=2 (0x14/0x17)", pin 0x14 comes up as an output (Pin-ctls
0x40) with its amplifier unmuted, and both speaker pairs play.
Assisted-by: OpenCode:deepseek-v4.1-flash checkpatch
Signed-off-by: Tarun Noonemunthala <ntarun2000@gmail.com>
Link: https://patch.msgid.link/20260923094014.58867-1-ntarun2000@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The ASUS SupremeFX Hi-Fi (0b05:1826, 0b05:1827) does not survive USB
autosuspend. After a suspend/resume cycle the firmware degrades: HID
probes begin to fail and the descriptors it returns become corrupted,
until the device stops responding entirely and needs a physical power
cycle to recover.
Add QUIRK_FLAG_DISABLE_AUTOSUSPEND for both product IDs.
Verified on 7.2.6 through the quirk_flags module parameter, with no
code change, and with the local udev rules that had been forcing
power/control commented out, so the parameter was the only mechanism
in play. Both IDs were passed as
0b05:1827:disable_autosuspend;0b05:1826:disable_autosuspend
The device then stayed awake across 2.5 hours (runtime_suspended_time
remained 0), survived a system suspend/resume cycle, and continued to
work afterwards with no failed probes and no power cycle needed.
Signed-off-by: Roman Bolotov <hadros@ikeepitoblique.com>
Link: https://patch.msgid.link/20260923064527.434441-1-hadros@ikeepitoblique.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The ThinkBook 16p Gen 3 ARH (SSID 17aa:3871) has a TI TAS2563
amplifier device on I2C, exposed by ACPI as INT8866, the same
arrangement as the Yoga 7 14ARB7 (SSID 17aa:3870). Without a quirk,
the codec falls back to the vendor-wide Lenovo quirk
(ALC269_FIXUP_LENOVO_XPAD_ACPI), the amplifier is never bound, and the
internal speakers stay silent while the headphone output works.
Reuse the Yoga 7 14ARB7 fixup, which binds the INT8866 device as a side
codec. ALC287_FIXUP_TAS2781_I2C does not work on this machine because it
looks for a TIAS2781 device.
Assisted-by: LLM
Signed-off-by: KIM MinWoo <phrimm136@gmail.com>
Link: https://patch.msgid.link/20260923013756.106033-1-phrimm136@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The mute LED on the HP Pavilion Gaming Laptop 15-ec1xxx (103c:87b2)
does not work automatically. Add the ALC285_FIXUP_HP_MUTE_LED quirk
to fix this behavior.
Signed-off-by: Luis Banha <luisbanha26@gmail.com>
Link: https://patch.msgid.link/20260921230105.16844-1-luisbanha26@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HP Pavilion 15 with the ALC3227 codec (SSID 103c:2164) exposes the full
four-step internal mic boost on pin 0x12: nsteps=3 with stepsize=0x2f, that is
0, 12, 24 and 36 dB. Combined with the ADC capture gain of +30 dB the analogue
cascade reaches 66 dB, and the internal microphone clips on the ambient noise of
a quiet room; the upper two steps are unusable at any useful input level. This
is the defect class ALC269_FIXUP_LIMIT_INT_MIC_BOOST exists for.
The machine matches no SSID quirk and falls through to the pin table, which
selects ALC269_FIXUP_HP_MUTE_LED_MIC1 through a pin signature shared with
several other HP models. Add an SSID entry instead, using
ALC269_FIXUP_LIMIT_INT_MIC_BOOST_MUTE_LED: the existing fixup that applies
alc269_fixup_limit_int_mic_boost() and chains to the same mute LED fixup, as
already done for 103c:218b. The boost becomes 0 or 12 dB and the LED handling is
unchanged.
Tested on the affected machine by selecting the same fixup through the model
string (snd-hda-intel.model), which bypasses the SSID and pin tables, with the
driver confirming the selection:
snd_hda_codec_alc269 hdaudioC1D0: ALC3227: picked fixup limit-mic-boost (model specified)
With that, Internal Mic Boost reports Limits 0 - 1 (0 or 12 dB) instead of 0 - 3
(0 to 36 dB), so alc269_fixup_limit_int_mic_boost() clamps this codec's internal
mic pin as intended. Note that /proc/asound/card1/codec#0 keeps printing the
unclamped hardware caps (nsteps=0x03): that file reads codec parameters uncached
by design, while the fixup overrides the driver's cached parameter that the
control is built from.
This does not by itself make the default capture volume sane -- the remaining
12 dB on top of the +30 dB ADC gain is still hotter than this machine's usable
operating point. It removes the two unusable steps from the hardware range, which
is what a quirk of this class can do.
Signed-off-by: Hernan Ganzo <gp@sneemgp.com>
Link: https://patch.msgid.link/20260921205538.41192-1-gp@sneemgp.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The HiBy FC4 with USB ID 32bb:0004 advertises its native DSD
stream as UAC2 RAW_DATA with a 4-byte, 32-bit subslot. Without a
quirk snd-usb-audio leaves this alternate setting as
SNDRV_PCM_FORMAT_SPECIAL, so userspace cannot select a native DSD
format.
Mark the device with QUIRK_FLAG_DSD_RAW so the existing generic raw
DSD handling exposes the stream as DSD_U32_BE.
Tested on an FC4 at DSD256. With the quirk the playback alternate
setting changes from SPECIAL to DSD_U32_BE and reports DOP=0,
bitrev=0; native DSD256 playback works correctly.
Signed-off-by: Achilles Zhang <bnqzzdf@gmail.com>
Link: https://patch.msgid.link/20260921024344.391912-1-bnqzzdf@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The PCI SSID quirk added for the Lenovo Yoga Pro 9 16IAH10 (PCI SSID
17aa:3846, codec SSID 17aa:3920) also matches every other machine that
shares PCI SSID 17aa:3846. snd_hda_pick_fixup() tries all PCI SSID entries
before it falls back to the codec SSID, so those machines now get
ALC287_FIXUP_YOGA9_SPEAKER2_TO_DAC1 and never reach their own
codec-SSID quirk.
The Lenovo Legion Pro 7 16IRX8H (product 82WQ) is one such machine: PCI
SSID 17aa:3846, codec SSID 17aa:3884. Before this quirk it picked
ALC287_FIXUP_TAS2781_I2C via the 17aa:3884 codec SSID fallback and bound
its TAS2781 amplifier. With it, the codec never binds the amplifier and
the internal speakers are silent:
snd_hda_codec_alc269 hdaudioC0D0: ALC287: picked fixup for PCI SSID 17aa:3846
versus, on a kernel without the quirk:
snd_hda_codec_alc269 hdaudioC0D0: ALC287: picked fixup for codec SSID 17aa:3884
snd_hda_codec_alc269 hdaudioC0D0: bound i2c-TIAS2781:00 (ops tas2781_hda_comp_ops ...)
Drop the PCI SSID entry. The Yoga Pro 9 16IAH10 has the same amplifier as
the Yoga S990-16 (codec SSID 17aa:3920), so it still gets a fixup through
the codec SSID fallback, using the existing 17aa:3920 entry. Switch that
entry from ALC287_FIXUP_TXNW2781_I2C to ALC287_FIXUP_YOGA9_SPEAKER2_TO_DAC1,
which applies the DAC routing fix and then chains to
ALC287_FIXUP_TXNW2781_I2C, so the amplifier setup is unchanged.
Fixes: 41d60cbfde10 ("ALSA: hda/realtek: Fix bass speaker DAC routing for Lenovo Yoga Pro 9 16IAH10")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=220540
Suggested-by: Zhang Heng <zhangheng@kylinos.cn>
Signed-off-by: Matt Barr <matthewjaybarr@gmail.com>
Link: https://patch.msgid.link/20260921214812.22139-1-matthewjaybarr@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Each playback URB is handed a slice of out.buffer that is exactly
LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT
endpoint, but the number of bytes written into that slice is never
compared against it.
submit_audio_out_urb() takes the frame count from prev_fsize, which
audio_in_callback() derived from the *IN* endpoint's received packet
length, and rescales it with the playback frame size; when prev_fsize is
still zero it synthesizes a length from the sample rate instead. On a
device declaring a large IN wMaxPacketSize and a small OUT
wMaxPacketSize, the resulting memcpy(), or the memset() when the
playback stream is idle, runs past its slice and, as the reproducer
below shows, beyond the allocation.
usb_submit_urb() is not a backstop. max_packet_size_out comes from
usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize,
while USB core validates a high-speed isochronous length against that
base scaled by usb_endpoint_maxp_mult(). A length of up to three times
the allocated slice is therefore accepted, and even a rejected URB is
only rejected after the write.
Reject a packet that does not fit the slice the driver allocated for it.
Clamping it instead would silently shorten the capture-derived rate
feedback and desynchronize the two streams.
BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229)
Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002
Workqueue: events line6_startup_work
Call Trace:
__asan_memcpy (mm/kasan/shadow.c:106)
submit_audio_out_urb (sound/usb/line6/playback.c:229)
line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291)
line6_stream_start (sound/usb/line6/pcm.c:194)
line6_pcm_acquire (sound/usb/line6/pcm.c:337)
line6_startup_work (sound/usb/line6/driver.c:728)
process_one_work (kernel/workqueue.c:3396)
worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
The buggy address belongs to the object at ffff888100bbd400
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes inside of
allocated 256-byte region [ffff888100bbd400, ffff888100bbd500)
Cc: stable@vger.kernel.org
Fixes: 7a0f55aeeb8f ("ALSA: line6: Support assymetrical in/out configurations")
Reported-by: <co+be8fa7ea6f77fdce@bugs.sh>
Assisted-by: LLM
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://patch.msgid.link/20260918234014.1318325-1-xmei5@asu.edu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
detect_usb_format() cross-checks bSubframeSize, bBitResolution and
tSamFreq between the capture and playback interfaces, but never relates
the two endpoints' wMaxPacketSize and bNrChannels. Each playback URB
gets a buffer of ua->playback.max_packet_bytes, while the number of
bytes written into it is derived from the capture stream:
capture_urb_complete() computes frames from the received capture packet
and capture.frame_bytes, and start_usb_playback() and playback_work()
multiply that by playback.frame_bytes.
A device declaring a large capture wMaxPacketSize with few capture
channels and a small playback wMaxPacketSize with many playback channels
therefore memset()s and memcpy()s past the end of the playback buffer,
in open() of the PCM node the driver registers during probe.
usb_submit_urb() rejects the over-long iso_frame_desc[0].length with
-EMSGSIZE, but only after the write.
Reject such descriptors at probe time. Genuine UA-101/UA-1000 hardware
declares proportional packet sizes and is unaffected.
BUG: KASAN: slab-out-of-bounds in start_usb_playback (sound/usb/misc/ua101.c:586)
Write of size 2048 at addr ffff8881098f3c00 by task exploit/5021
Call Trace:
__asan_memset (mm/kasan/shadow.c:84)
start_usb_playback (sound/usb/misc/ua101.c:586)
playback_pcm_open (sound/usb/misc/ua101.c:679)
snd_pcm_open_substream (sound/core/pcm_native.c:2829)
snd_pcm_open (sound/core/pcm_native.c:2865 sound/core/pcm_native.c:2932)
snd_pcm_playback_open (sound/core/pcm_native.c:2891)
snd_open (sound/core/sound.c:166)
chrdev_open (fs/char_dev.c:411)
do_dentry_open (fs/open.c:996)
vfs_open (fs/open.c:1101)
path_openat (fs/namei.c:4837 fs/namei.c:5000)
do_file_open (fs/namei.c:5029)
do_sys_openat2 (fs/open.c:1417)
__x64_sys_openat (fs/open.c:1423 fs/open.c:1439 fs/open.c:1434)
do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
The buggy address belongs to the object at ffff8881098f3c00
which belongs to the cache kmalloc-192 of size 192
The buggy address is located 0 bytes inside of
allocated 168-byte region [ffff8881098f3c00, ffff8881098f3ca8)
Cc: stable@vger.kernel.org
Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support")
Reported-by: <co+24304d323d28f156@bugs.sh>
Assisted-by: LLM
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://patch.msgid.link/20260918225753.1278505-1-xmei5@asu.edu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|