mirror of
https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10.git
synced 2026-09-09 00:07:04 +08:00
main
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Jaroslav Kysela
|
6928d460a6 |
ALSA: hda/realtek: Add quirk for TongFang X6SP45xU
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 26a94400ffa4fcbeff32e23abebb83a1a20eb401 Author: Eckhart Mohr <e.mohr@tuxedocomputers.com> Date: Fri Jul 24 21:00:13 2026 +0200 ALSA: hda/realtek: Add quirk for TongFang X6SP45xU TongFang X6KK45xU and X6SP45xU have actually different PCI IDs. This patch Adds the missing PCI ID to fix headphone detection and clarifies the naming. Fixes: d595255241e5 ("ALSA: hda/realtek: Add quirk for TongFang X6xx45xU") 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/20260724190109.169889-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
c81ca245fe |
ASoC: amd: ps: disable MSI on resume in ACP PCI driver
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 5893013efabb056399a01e267f410cf76eba25eb Author: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Date: Tue Jul 7 11:29:36 2026 +0530 ASoC: amd: ps: disable MSI on resume in ACP PCI driver BIOS/firmware may re-enable MSI in PCI config space during system level resume even though this driver only uses legacy INTx interrupts. If MSI is left enabled with stale address/data registers, the device will write interrupts to a bogus address causing IOMMU IO_PAGE_FAULT and interrupt delivery failure. Clear the MSI Enable bit before reinitializing the ACP hardware on system level resume. Fixes: 491628388005 ("ASoC: amd: ps: add callback functions for acp pci driver pm ops") Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260707060130.2514138-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
3f8f9de549 |
ALSA: hda/tas2781: Fix device-0 reset issue and handle -EXDEV in block data processing
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 513480da5e9c8f55b4f8f5e89f386e26188fbb3f Author: Baojun Xu <baojun.xu@ti.com> Date: Tue Jun 9 18:52:53 2026 +0800 ALSA: hda/tas2781: Fix device-0 reset issue and handle -EXDEV in block data processing Fix reset for device-0: In older projects (e.g., Merino), the hardware reset pin for the first SPI device (device-0) is ineffective, causing initialization failures. Added a software reset sequence for device-0 to ensure proper initialization. Handle -EXDEV correctly: When processing block data, if the data does not belong to the current SPI device, the driver returned -EXDEV. This error code is now ignored to allow the driver to continue iterating through the block data and correctly calculate the total block size. Signed-off-by: Baojun Xu <baojun.xu@ti.com> Link: https://patch.msgid.link/20260609105253.19510-1-baojun.xu@ti.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
8718ead3cf |
ALSA: hda/tas2781: Cancel async firmware request at unbind
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 5367e2ad14f0ae9350a7aaf2e77c87de39a43ae9
Author: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Date: Tue May 5 08:18:17 2026 -0300
ALSA: hda/tas2781: Cancel async firmware request at unbind
TAS2781 HDA I2C and SPI queue RCA firmware loading from component
bind with request_firmware_nowait(). The firmware loader keeps the
callback module pinned and holds a device reference, but the callback
still uses driver-private HDA state.
Component unbind removes controls and DSP state immediately. Later
device removal tears down the TAS2781 private data, including
codec_lock. If the async firmware callback runs after unbind has
started, it can operate on state that is being torn down.
Cancel or synchronize the async firmware request before removing
controls and DSP state. A queued callback is cancelled, and an
already-running callback is allowed to finish before unbind continues.
Fixes:
|
||
|
Jaroslav Kysela
|
1fef8dedce |
firmware_loader: Add cancel helper for async requests
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit b9bdd68b8b979c7e9de58b2e7d21e1d7d932c755 Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Tue May 5 08:18:16 2026 -0300 firmware_loader: Add cancel helper for async requests request_firmware_nowait() keeps the callback module pinned and holds a device reference until the firmware work completes. Callers still have no way to cancel or synchronize the queued callback before tearing down their driver-private state. Track scheduled async firmware work in an internal list and add request_firmware_nowait_cancel(). The helper cancels work matching the device, callback context and callback function. It cancels work that has not started yet and waits for an already-running callback to return. If the request has already completed, it is a no-op. Keep the existing request_firmware_nowait() lifetime model manual. A devres-managed variant can be layered on top separately if needed. Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260505-alsa-hda-tas2781-fw-callback-teardown-v4-1-e7c4bf930dc8@gmail.com Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
a045926b1a |
ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 3ca15754b561483aa7a1bce51677d6389f8ff5bb
Author: Geoffrey D. Bennett <g@b4.vu>
Date: Sun Apr 26 06:47:14 2026 +0930
ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417
Firmware 2417 for the Scarlett 4th Gen 2i2 moved the direct monitor gain
parameters, so add a second config_set with the shifted offset and
select it for firmware versions >= 2417.
Fixes:
|
||
|
Jaroslav Kysela
|
c906889cb5 |
ALSA: scarlett2: Allow selecting config_set by firmware version
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 732a6397a526c025cd29c3c9309b0db6a2c08837 Author: Geoffrey D. Bennett <g@b4.vu> Date: Sun Apr 26 06:46:30 2026 +0930 ALSA: scarlett2: Allow selecting config_set by firmware version The Scarlett 2i2 Gen 4 firmware 2417 moved the direct monitor gain parameters, so we now need to allow each device to list multiple scarlett2_config_set entries, one per applicable firmware version range, and pick the matching one at probe time. No functional change yet: each device gets a single config_sets entry whose from_firmware_version matches the existing min_firmware_version (0 where none was set). This both prepares for selection and lets a follow-up commit remove the now-redundant min_firmware_version field. scarlett2_count_io() depends on the resolved config_set so it moves out of scarlett2_init_private() into snd_scarlett2_controls_create() after the firmware version has been read. Signed-off-by: Geoffrey D. Bennett <g@b4.vu> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/ae1695b4c4825f365b4c86b22174035f742807e3.1777151532.git.g@b4.vu Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
7a2bead43d |
ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 2e9261761b35f0b67b7487688cd1365f535be0b3
Author: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Date: Tue Jun 16 18:02:57 2026 +0100
ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback
When q6apm_free_fragments() is called it frees rx_data.buf/tx_data.buf
and sets them to NULL under graph->lock. A late DSP buffer-done response
can race with this: graph_callback() passes the !graph->ar_graph guard
(not yet NULL), acquires the lock, but then dereferences a now-NULL buf
pointer to read buf[token].phys, crashing at virtual address 0x10.
Add a NULL check for buf inside the mutex-protected section in both the
write-done (DATA_CMD_RSP_WR_SH_MEM_EP_DATA_BUFFER_DONE_V2) and
read-done (DATA_CMD_RSP_RD_SH_MEM_EP_DATA_BUFFER_V2) handlers and bail
out cleanly if buffers have already been freed.
This problem is only shown up recently while apr bus was updated to
process the commands per service rather from single global queue.
Fixes:
|
||
|
Jaroslav Kysela
|
1d8b12674f |
ASoC: mediatek: mt8183: Release reserved memory on cleanup
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit bee65e00c0924ebecf97718d95dcf4a05ee36471 Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Wed May 27 10:41:48 2026 -0300 ASoC: mediatek: mt8183: Release reserved memory on cleanup The MT8183 AFE probe can assign reserved memory with of_reserved_mem_device_init(), but the assignment is never released on driver removal or later probe failures. Register a devm cleanup action so the reserved memory assignment is released consistently, matching newer Mediatek AFE drivers. Fixes: ec4a10ca4a68 ("ASoC: mediatek: use reserved memory or enable buffer pre-allocation") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260527-asoc-mt8183-probe-cleanup-v1-1-4f4f5593c8d1@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
88330f0994 |
ASoC: mediatek: mt8183: Check runtime resume during probe
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit f0334fbfd107682d0c95f3f71e25f6127038e2b9
Author: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Date: Wed May 27 10:41:49 2026 -0300
ASoC: mediatek: mt8183: Check runtime resume during probe
The MT8183 AFE probe uses pm_runtime_get_sync() before reading hardware
defaults into the regmap cache, but does not check whether runtime resume
failed. If regmap_reinit_cache() then fails, the temporary runtime PM
usage count is also not released.
Use pm_runtime_resume_and_get() so resume failures abort probe without
leaking a usage count, and release the temporary reference before
handling the regmap cache result.
Fixes:
|
||
|
Jaroslav Kysela
|
570eedb92d |
ASoC: mediatek: mt8192: Release reserved memory on cleanup
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 965e17ae6751c5d3302430c8ebd650e72d45a85f Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Wed May 27 10:55:46 2026 -0300 ASoC: mediatek: mt8192: Release reserved memory on cleanup The MT8192 AFE probe calls of_reserved_mem_device_init() and falls back to preallocated buffers when no reserved memory region is available. When the reserved memory assignment succeeds, however, the driver never releases it. Register a devm cleanup action after a successful reserved-memory assignment so the assignment is released on probe failure and driver unbind. Fixes: ec4a10ca4a68 ("ASoC: mediatek: use reserved memory or enable buffer pre-allocation") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260527-asoc-mt8192-probe-cleanup-v1-1-1bb834d05b72@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
874958d8c2 |
ASoC: mediatek: mt8192: Check runtime resume during probe
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit e24d5dde56a50946020b134fa8448869093db76a
Author: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Date: Wed May 27 10:55:47 2026 -0300
ASoC: mediatek: mt8192: Check runtime resume during probe
The MT8192 AFE probe enables runtime PM temporarily while reinitializing
the regmap cache from hardware, but it uses pm_runtime_get_sync()
without checking the return value. If runtime resume fails, probe keeps
going without the device necessarily being accessible, and
pm_runtime_get_sync() may leave the PM usage count incremented.
The regmap_reinit_cache() failure path also returns before dropping the
temporary PM reference and before clearing pm_runtime_bypass_reg_ctl.
Use pm_runtime_resume_and_get() so resume failures do not leak a usage
count, and clear the temporary bypass flag after dropping the probe PM
reference on all regmap_reinit_cache() outcomes.
Fixes:
|
||
|
Jaroslav Kysela
|
9a82b8886b |
ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 390aa4c9339bb0ec0bc8d554e830faf93ca9d49e
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date: Tue Jun 9 11:34:56 2026 +0300
ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control
In snd_sof_update_control(), firmware-provided cdata->num_elems is
checked against local_cdata->data->size but never against the actual
allocation size. If local_cdata->data->size was previously set to an
inconsistent value, the memcpy could write past the allocated buffer.
Add a bounds check to ensure num_elems fits within the available space
in the ipc_control_data allocation before copying.
Fixes:
|
||
|
Jaroslav Kysela
|
d2add62d90 |
ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit fd46668d538993218eea19c6925c868ac0f2630c
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date: Tue Jun 9 11:34:58 2026 +0300
ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get
The ipc_control_data buffer is allocated as kzalloc(max_size), where
max_size covers the entire struct sof_ipc_ctrl_data including its
flexible array payload. However, the bounds checks in bytes_ext_put
and _bytes_ext_get compared user data lengths against max_size
directly, ignoring that cdata->data sits at an offset of
sizeof(struct sof_ipc_ctrl_data) bytes into the allocation.
This allowed writing up to sizeof(struct sof_ipc_ctrl_data) bytes past
the end of the heap buffer from unprivileged userspace via the ALSA TLV
kcontrol interface, and similarly allowed over-reading adjacent heap
data on the get path.
Fix all bounds checks to subtract sizeof(*cdata) from max_size so they
reflect the actual space available at the cdata->data offset. Also fix
the error-path restore in bytes_ext_put which wrote to cdata->data
instead of cdata, causing the same overflow.
Fixes:
|
||
|
Jaroslav Kysela
|
af33a7d73e |
ASoC: SOF: topology: fix memory leak in snd_sof_load_topology
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit d46f9f23897261da53ffbeb89d48a13982ba7d28 Author: Zhao Dongdong <zhaodongdong@kylinos.cn> Date: Wed Jun 10 15:20:43 2026 +0800 ASoC: SOF: topology: fix memory leak in snd_sof_load_topology When the topology filename contains "dummy" and tplg_cnt is 0, the function returns -EINVAL directly without freeing the tplg_files allocated by kcalloc() at line 2497. This leaks memory on every such topology load attempt. Fix this by setting ret = -EINVAL and jumping to the out: label, which already handles the kfree(tplg_files) cleanup. Fixes: 225d70b80745 ("ASoC: SOF: don't check the existence of dummy topology") Cc: stable@vger.kernel.org Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn> Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://patch.msgid.link/tencent_3EED6D778DC52C3703A2D1EE8119372E8E08@qq.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
aa3d167786 |
ASoC: SOF: topology: validate vendor array size before parsing
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 8468dd79cfb2ffbdeaf7c353f63d64941cb8ba05 Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Wed Jun 3 14:57:54 2026 -0300 ASoC: SOF: topology: validate vendor array size before parsing sof_parse_token_sets() reads array->size while iterating over topology private data. The loop condition only checks that some data remains, so a malformed topology with a truncated trailing vendor array can make the parser read the size field before a full vendor-array header is available. Validate that the remaining private data contains a complete snd_soc_tplg_vendor_array header before reading array->size. The declared array size check also needs to remain signed. asize is an int, but sizeof(*array) has type size_t, so comparing them directly promotes negative asize values to unsigned and lets them pass the check, as reported in the stable review thread reference below. Cast sizeof(*array) to int when validating the declared array size. This rejects negative, zero and otherwise too-small sizes before the parser dispatches to the tuple-specific code. Link: https://lore.kernel.org/stable/CANiDSCsjR5NHqu_Ui5cOqWdJgFqmYsQ9WR8O7m0WOhngaYXFpw@mail.gmail.com/t/#m9b3be379221e79327cc13fd71009287368ef4f23 Fixes: 215e5fe75881 ("ASoC: SOF: topology: reject invalid vendor array size in token parser") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260603-sof-topology-array-size-signed-v1-1-84f97879a4ef@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
b7d715522a |
ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 1f97760417b5faa60e9642fd0ed61eb17d0b1b39
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date: Tue Jun 9 11:34:57 2026 +0300
ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get
In sof_ipc3_bytes_put(), the size used for the memcpy is derived from
the old data->size already in the buffer, not the incoming new data's
size field. If the new data has a different size, the copy length is
wrong: it may truncate valid data or copy stale bytes.
Similarly, sof_ipc3_bytes_get() checks data->size against max_size
without accounting for the sizeof(struct sof_ipc_ctrl_data) offset
of the flex array within the allocation.
Fix bytes_put to validate and use the incoming data's sof_abi_hdr.size
from ucontrol before copying. Fix bytes_get to subtract sizeof(*cdata)
from the bounds check to match the actual available space.
Fixes:
|
||
|
Jaroslav Kysela
|
da630bb48c |
ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 8791977d7289f6e9d2b014f60a5455f053a7bc04
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date: Tue Jun 9 11:34:55 2026 +0300
ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc
In sof_ipc3_control_update(), the expected_size calculation uses
firmware-provided cdata->num_elems in arithmetic that could overflow
on 32-bit platforms, wrapping to a small value. This would allow the
cdata->rhdr.hdr.size comparison to pass with mismatched sizes,
potentially leading to out-of-bounds access in snd_sof_update_control.
Use check_mul_overflow() and check_add_overflow() to detect and reject
overflowed size calculations.
Fixes:
|
||
|
Jaroslav Kysela
|
415240a3b5 |
ASoC: SOF: ipc4-control: Validate notification payload size
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 5bdfeccb7fbf6e000fc783cd8412732e67c1ad0c Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Date: Tue Jun 9 11:34:54 2026 +0300 ASoC: SOF: ipc4-control: Validate notification payload size Validate MODULE_NOTIFICATION payload length before reading bytes/channel data in control update handling. Fixes: 2a28b5240f2b ("ASoC: SOF: ipc4-control: Add support for generic bytes control") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20260609083458.31193-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
8df75c63cd |
ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 3ad673e7139cf214afd24321a829aad6575f4163
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date: Tue Jun 9 11:34:53 2026 +0300
ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put
In sof_ipc4_bytes_put(), the copy size is derived from the old
data->size in the buffer rather than the incoming new data's size
field from ucontrol. If the new data has a different size, the copy
uses the wrong length: it may truncate valid data or copy stale bytes.
Fix by validating and using the incoming data's sof_abi_hdr.size from
ucontrol before copying.
Fixes:
|
||
|
Jaroslav Kysela
|
683b6b3b3b |
ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 0773610eef71c30df3cb4c113c8215625d2a7c23
Author: Luca Weiss <luca.weiss@fairphone.com>
Date: Tue May 26 17:03:05 2026 +0200
ASoC: codecs: lpass-va-macro: Fix LPASS Codec Version for SC7280
According to both the static definition in downstream...
yupik-audio-overlay.dtsi: qcom,bolero-version = <4>;
#define BOLERO_VERSION_2_0 0x0004)
and the runtime detection:
CDC_VA_TOP_CSR_CORE_ID_0=0x1
CDC_VA_TOP_CSR_CORE_ID_1=0xf
SC7280 has LPASS Codec Version 2.0 and not, as declared with
sm8250_va_data LPASS_CODEC_VERSION_1_0.
Create new va_macro_data with .version not set to use the runtime
detection and correctly get .version = LPASS_CODEC_VERSION_2_0.
Fixes:
|
||
|
Jaroslav Kysela
|
9edd2d4653 |
ALSA: FCP: Fix NULL pointer dereference in interface lookup
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit e1e31e0ec8a609e17fd2e86b77bc00d9cbb24d7c Author: Jiaming Zhang <r772577952@gmail.com> Date: Thu Jun 25 21:49:33 2026 +0800 ALSA: FCP: Fix NULL pointer dereference in interface lookup A malformed USB device can provide a vendor-specific interface without any endpoint descriptors. fcp_find_fc_interface() currently selects the first vendor-specific interface and reads endpoint 0 from it, without checking whether the interface actually has any endpoints. When bNumEndpoints is zero, no endpoint array is allocated for the parsed alternate setting, so get_endpoint(..., 0) yields an invalid endpoint descriptor pointer. Dereferencing it through usb_endpoint_num() then triggers a NULL pointer dereference. Skip vendor-specific interfaces that do not have any endpoints. Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver") Reported-by: Jiaming Zhang <r772577952@gmail.com> Closes: https://lore.kernel.org/lkml/CANypQFb1EHj0xX8bA1WxSOSK-5xca6ZNKzOQcp12=s=puY7VFw@mail.gmail.com/ Signed-off-by: Jiaming Zhang <r772577952@gmail.com> Link: https://patch.msgid.link/20260625134933.425785-1-r772577952@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
315b4b2803 |
ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit cf6f56990ea21172e085f0588e5bbf2089ce8f58
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date: Thu Jun 25 18:24:16 2026 +0800
ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count
The back-end consumes data in units of the number of channels. When the
maxburst value is not evenly divisible by the channel count, the DMA
transfer length does not align with the FIFO frame boundary, causing
wrong data to be copied and audible noise at the end of the stream.
This is specific to eDMA: eDMA only responds to DMA requests from the
back-end, whereas SDMA handles requests from both the front-end and the
back-end and is not affected.
For eDMA, when the back-end maxburst is not evenly divisible by the
channel count, align it to the nearest valid boundary:
- If maxburst >= channel count, override to the channel count so each
transfer corresponds to exactly one audio frame.
- If maxburst < channel count, override to 1 to avoid partial-frame
transfers.
Retain the original maxburst for SDMA or when it already aligns with
the channel count.
Fixes:
|
||
|
Jaroslav Kysela
|
1c92de0d48 |
ASoC: rt5575: Use __le32 for SPI burst write address
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit d0c415f0076b71b956f62ff6f31de885f0fa2489 Author: Oder Chiou <oder_chiou@realtek.com> Date: Tue Jun 23 18:25:14 2026 +0800 ASoC: rt5575: Use __le32 for SPI burst write address The addr field in the SPI burst write buffer represents on-wire little-endian data. Define it as __le32 so that the assignment of cpu_to_le32() is type correct and avoids sparse endian warnings. Closes: https://lore.kernel.org/oe-kbuild-all/202606230139.rFZUVpCa-lkp@intel.com/ Fixes: 420739112e95 ("ASoC: rt5575: Add the codec driver for the ALC5575") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Oder Chiou <oder_chiou@realtek.com> Link: https://patch.msgid.link/20260623102514.2422990-1-oder_chiou@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
0b2ef5c740 |
ASoC: SDCA: Validate written enum value in ge_put_enum_double()
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 1ce42a11bed134903e352010a01fa53073a6b395 Author: HyeongJun An <sammiee5311@gmail.com> Date: Tue Jun 23 20:05:26 2026 +0900 ASoC: SDCA: Validate written enum value in ge_put_enum_double() ge_put_enum_double() passes the user-supplied enumeration index item[0] to snd_soc_enum_item_to_val() without checking it against the number of items in the enum: ret = snd_soc_enum_item_to_val(e, item[0]); snd_soc_enum_item_to_val() indexes the heap-allocated e->values[] array with that index (e->values is set from a devm_kcalloc() of e->items entries), so a control write with an out-of-range item[0] reads past the end of the values buffer. The bounds check in snd_soc_dapm_put_enum_double() only runs afterwards, so it does not prevent the read here. Reject an out-of-range item before using it, matching the other enum put handlers. This issue was pointed out by the Sashiko AI review bot while reviewing a related enum-validation series: https://lore.kernel.org/all/20260609125735.CEB651F00893@smtp.kernel.org/ Fixes: 812ff1baa764 ("ASoC: SDCA: Limit values user can write to Selected Mode") Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260623110526.813217-1-sammiee5311@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
5f9f542ad5 |
ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit cf81b260916c92cf610c907d41627a175e86e37d
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date: Wed Jun 17 16:47:53 2026 +0200
ASoC: cs530x: Fix expected MCLK rates for CS5302/4/8
When this driver was first added, it accepted rates of 24.56 MHz and
22.572 MHz for the MCLK when PLL bypass is enabled.
These rates seem to have no basis in the datasheets and were thus replaced
with 45.1584 MHz and 49.152 MHz, respectively, in commit e7ab858390f2
("ASoC: cs530x: Correct MCLK reference frequency values").
While the new rates are indeed correct for the CS4xxx ICs[0][1][2][3],
they are incorrect for the CS530x ICs the driver was originally written to
support as the MCLK frequencies are halved there[4][5][6].
Fix this by checking against the correct type-appropriate rates.
While at it, drop the CS530X_SYSCLK_REF_* macros. They arguably confuse
more than they help, especially as they are not applicable to the
cs5302/4/8.
[0]: https://statics.cirrus.com/pubs/proDatasheet/CS4282P_DS1318F1.pdf
[1]: https://statics.cirrus.com/pubs/proDatasheet/CS4302P_DS1315F1.pdf
[2]: https://statics.cirrus.com/pubs/proDatasheet/CS4304P_DS1316F1.pdf
[3]: https://statics.cirrus.com/pubs/proDatasheet/CS4308P_DS1317F1.pdf
[4]: https://statics.cirrus.com/pubs/proDatasheet/CS5302P_DS1312F1.pdf
[5]: https://statics.cirrus.com/pubs/proDatasheet/CS5304P_DS1313F1.pdf
[6]: https://statics.cirrus.com/pubs/proDatasheet/CS5308P_DS1314F1.pdf
Fixes:
|
||
|
Jaroslav Kysela
|
7c07d18dee |
ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit f199c8a8bdd54296d3458777e70fe82a78bd9817
Author: Cen Zhang <zzzccc427@gmail.com>
Date: Fri Jun 19 01:00:10 2026 +0800
ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints
MIDI 2.0 input URBs are started during snd_usb_midi_v2_create(). A
later setup failure can still jump to snd_usb_midi_v2_free(), which
currently frees each endpoint and its coherent URB buffers without first
stopping the submitted URBs. A completion can then dereference the
embedded URB context and endpoint state after they have been freed, or
try to resubmit from the stale endpoint.
This was observed as a KASAN slab-use-after-free in
input_urb_complete().
The buggy scenario involves two paths, with each column showing the order
within that path:
probe error path: USB completion path:
1. start_input_streams() submits 1. The HCD still owns a
input URBs. submitted input URB.
2. A later setup helper returns 2. input_urb_complete() runs
an error. with urb->context in ep.
3. snd_usb_midi_v2_free() frees 3. The completion reads ep
endpoint storage and URB buffers. state and can requeue URBs.
Make the endpoint destructor follow the same teardown ordering used for
disconnect when the endpoint has not already been disconnected: publish
ep->disconnected, kill the URBs synchronously, and drain the endpoint
before freeing URB buffers and endpoint storage. The guard avoids
repeating the stop sequence after the normal
snd_usb_midi_v2_disconnect_all() path, while still synchronizing the
direct MIDI 2.0 create-error free path.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in input_urb_complete+0x37/0x1b0
Workqueue: usb_hub_wq hub_event
RIP: 0010:_raw_spin_unlock_irq+0x2e/0x50
Read of size 8
Call trace:
dump_stack_lvl+0x77/0xb0
print_report+0xce/0x5f0
input_urb_complete+0x37/0x1b0 (sound/usb/midi2.c:186)
srso_alias_return_thunk+0x5/0xfbef5
__virt_addr_valid+0x19f/0x330
kasan_report+0xe0/0x110
__usb_hcd_giveback_urb+0x112/0x1d0
dummy_timer+0xaaa/0x19a0
lock_is_held_type+0x9a/0x110
__lock_acquire+0x467/0x28b0
mark_held_locks+0x40/0x70
_raw_spin_unlock_irqrestore+0x44/0x60
lockdep_hardirqs_on_prepare+0xbb/0x1a0
__hrtimer_run_queues+0x101/0x520
hrtimer_run_softirq+0xd0/0x130
handle_softirqs+0x15b/0x670
__irq_exit_rcu+0xd0/0x170
irq_exit_rcu+0xe/0x20
sysvec_apic_timer_interrupt+0x6c/0x80
asm_sysvec_apic_timer_interrupt+0x1a/0x20
Fixes:
|
||
|
Jaroslav Kysela
|
b1af80caf8 |
ALSA: usb-audio: qcom: clear opened when stream enable fails
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 3c7af07943b2718087ae791cad450af5cf646d90 Author: Michael Bommarito <michael.bommarito@gmail.com> Date: Wed Jun 17 22:51:26 2026 -0400 ALSA: usb-audio: qcom: clear opened when stream enable fails On enable, subs->opened is set before the service_interval is validated; an invalid interval jumps to the response label without clearing it, so the substream is wedged at -EBUSY until a disable or disconnect. Clear subs->opened on the enable error path. Fixes: 326bbc348298a ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Link: https://patch.msgid.link/20260618025126.1862954-3-michael.bommarito@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
9be042cf28 |
ALSA: usb-audio: qcom: reject stream disable with no active interface
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit bdb640be82e645e2828731648f485224d0c2587b Author: Michael Bommarito <michael.bommarito@gmail.com> Date: Wed Jun 17 22:51:25 2026 -0400 ALSA: usb-audio: qcom: reject stream disable with no active interface handle_uaudio_stream_req() resolves an interface index with info_idx_from_ifnum(), which returns -EINVAL when no interface matches. The enable branch and the response: cleanup label both guard against a negative index, but the disable branch does not: it forms info = &uadev[pcm_card_num].info[info_idx] and dereferences it. uadev[].info is a pointer allocated only when a stream is first enabled, so a negative info_idx on the disable path is unsafe in two ways: - If the card was never enabled, .info is NULL and &info[-EINVAL] is a wild pointer; reading info->data_ep_pipe faults (kernel oops). - If the card was enabled at least once (.info allocated) and the disable names an interface that does not match, &info[-EINVAL] points before the allocation; info->data_ep_pipe / info->sync_ep_pipe are an out-of-bounds slab read and, when non-zero, an out-of-bounds 4-byte write (both pipe fields are cleared to 0). That is memory corruption, not just a NULL dereference. The request is reachable from unprivileged local userspace over AF_QIPCRTR. Reject a disable request with no resolved interface, matching the guard the enable path already has. Fixes: 326bbc348298a ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Link: https://patch.msgid.link/20260618025126.1862954-2-michael.bommarito@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
ad888e0f12 |
ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit fdf043f5f3bae150b678feae3d7bb1beed87ec14
Author: Sen Wang <sen@ti.com>
Date: Tue Jun 16 18:33:22 2026 -0500
ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode
The datasheet documents that when the PLL is disabled and dual-rate mode
is enabled, only Q values {4, 8, 9, 12, 16} are valid for the CLKDIV
bypass path; all other Q values produce invalid bitclock output.
The existing loop iterates Q from 2 to 17 without this restriction,
causing silent audio failure when an out-of-spec Q is picked.
Restrict the Q search to the allowed set in dual-rate mode.
Fixes:
|
||
|
Jaroslav Kysela
|
3f1c552e07 |
ALSA: usb-audio: qcom: Free sideband sg_table objects
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 7d69804a35103a50852eae41bfe6a2e0061c68fd Author: Xu Rao <raoxu@uniontech.com> Date: Tue Jun 16 19:59:16 2026 +0800 ALSA: usb-audio: qcom: Free sideband sg_table objects The Qualcomm USB audio offload driver obtains an endpoint transfer-ring table by calling xhci_sideband_get_endpoint_buffer(). This getter passes the endpoint ring to xhci_ring_to_sgtable(), which allocates the outer struct sg_table with kzalloc_obj(*sgt). The event-ring path is equivalent: xhci_sideband_get_event_buffer() also returns the result of xhci_ring_to_sgtable(). Inside xhci_ring_to_sgtable(), sg_alloc_table_from_pages() separately allocates the scatterlist storage referenced by sgt->sgl. The returned object therefore has two allocation layers: the outer struct sg_table and its internal scatterlist storage. The Qualcomm caller only invokes sg_free_table(sgt). sg_free_table() releases the scatterlist storage owned by the table, but it does not free the separately allocated outer struct sg_table. The local sgt pointer is then discarded, so every successful endpoint or event-ring query leaks the outer object. Call kfree(sgt) after sg_free_table(sgt) in both setup paths, after the required page and DMA addresses have been copied out. Fixes: 326bbc348298 ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Signed-off-by: Xu Rao <raoxu@uniontech.com> Link: https://patch.msgid.link/90B353283AA150C4+20260616115916.1222915-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
4c85abed71 |
soundwire: intel_ace2x: release bpt_stream when close it
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 8a7fe10eec64bfb7cf4091bca540de4c55d56bfa Author: Bard Liao <yung-chuan.liao@linux.intel.com> Date: Thu May 14 22:16:25 2026 +0800 soundwire: intel_ace2x: release bpt_stream when close it The BPT stream was allocated in intel_ace2x_bpt_open_stream(), we need to free it in intel_ace2x_bpt_close_stream(). Fixes: 4c1ce9f37d8a8 ("soundwire: intel_ace2x: add BPT send_async/wait callbacks") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Simon Trimmer <simont@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260514141625.1834216-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
36ce824656 |
soundwire: fix bug in sdw_add_element_group_count found by syzkaller
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit f772ff5a0e6758fd412803c09e03ba3bca5f5878
Author: Baoli.Zhang <baoli.zhang@linux.intel.com>
Date: Wed May 6 13:50:35 2026 +0800
soundwire: fix bug in sdw_add_element_group_count found by syzkaller
The original implementation caused an out-of-bounds memory access
in the sdw_add_element_group_count for-loop when i == num.
for (i = 0; i <= num; i++) {
if (rate == group->rates[i] && lane == group->lanes[i])
...
To fix this error, the function now checks for existing rate/lane
entries in the group(a function parameter) using a for-loop before
adding them.
No functional changes apart from this fix.
Fixes:
|
||
|
Jaroslav Kysela
|
50bdbdd281 |
soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached Peripheral
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit c368dd5cbd61ffab2b6f8a89b0d5775e2e16cde6 Author: Bard Liao <yung-chuan.liao@linux.intel.com> Date: Tue Apr 28 16:46:12 2026 +0800 soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached Peripheral The SDW_SCP_BUSCLOCK_SCALE register will be programmed when the Peripheral is attached. We can and should skip programming the SDW_SCP_BUSCLOCK_SCALE register when the Peripheral is unattached. Fixes: 645291cfe5e5 ("Soundwire: stream: program BUSCLOCK_SCALE") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Simon Trimmer <simont@opensource.cirrus.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20260428084612.322701-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
04c5518a65 |
mfd: cs42l43: Sanity check firmware size
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit b6ef1a74b3ec254f87a6a3c554fe8f8083ebd37c
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date: Fri May 8 14:48:04 2026 +0100
mfd: cs42l43: Sanity check firmware size
Currently the code checks if a firmware was received, however it does
not verify that the firmware size is larger than the firmware header. As
the firmware pointer is dereferenced as a pointer to the header
structure this could lead to an out of bounds memory access. Add the
missing check.
Fixes:
|
||
|
Jaroslav Kysela
|
a5dcb4c642 |
ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit b113a891252c3fa4fab11ec8c2894a22ecaf278c
Author: Takashi Iwai <tiwai@suse.de>
Date: Sun Jun 14 11:05:05 2026 +0200
ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()
snd_power_ref_and_wait() takes the power refcount and doesn't leave it
no matter whether it returns an error or not. However, the majority
of callers don't expect but just returns without unreferencing in the
caller side upon errors.
For addressing the potential refcount unbalance, rather correct the
behavior of snd_power_ref_wait() to unreference upon returning an
error.
Note that the problem above is likely negligible; the function returns
an error only when the sound card is being shutdown, hence it doesn't
matter about the power refcount any longer at such a state.
Fixes:
|
||
|
Jaroslav Kysela
|
3086958a2b |
ALSA: seq: avoid stale FIFO cells during resize
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit e546128291f8d688dcb931827e2efd2aa6c0734d
Author: Cen Zhang <zzzccc427@gmail.com>
Date: Sun Jun 14 08:48:01 2026 +0800
ALSA: seq: avoid stale FIFO cells during resize
snd_seq_fifo_resize() still needs to publish the replacement pool
before it waits for FIFO users. A blocking snd_seq_read() holds
f->use_lock while it sleeps, so concurrent senders must be able to
queue to the new pool and wake that reader instead of failing against a
closing old pool.
However, snd_seq_fifo_event_in() duplicates an event before it takes
f->lock, and snd_seq_read() can dequeue a cell and later call
snd_seq_fifo_cell_putback() if copy_to_user() or
snd_seq_expand_var_event() fails. If resize swaps f->pool and detaches
oldhead in between, either path can relink an old-pool cell after the
snapshot. That stale cell sits outside the drained oldhead list, keeps
oldpool->counter elevated, and can leave snd_seq_pool_delete() waiting
for the retired pool to drain.
Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(),
but reject stale cells before any FIFO relink. Revalidate event-in cells
under f->lock and retry them against the published replacement pool, and
free stale putback cells instead of linking them back into the FIFO.
The buggy scenario involves two paths, with each column showing the
order within that path:
resize path: relink path:
1. Allocate newpool. 1. Take f->use_lock.
2. Swap f->pool to newpool and 2. Duplicate or dequeue an old-pool
detach oldhead. cell before oldpool closes.
3. Mark oldpool closing and 3. Reach a later relink point after
wait for FIFO users. resize published newpool.
4. Free oldhead and delete 4. Relink the old-pool cell after
oldpool. resize detached oldhead.
5. Drop f->use_lock.
The reproducer reports a resize ioctl blocked in the expected pool
teardown path:
signal: resize iteration=98 target_pool=4 exceeded 250ms
(elapsed=251ms)
diagnostic: resize_tid=651 wchan=snd_seq_pool_done
diagnostic: resize_tid=651 stack=
snd_seq_pool_done+0x5b/0x140
snd_seq_pool_delete+0x7a/0x90
snd_seq_fifo_resize+0x193/0x1e0
snd_seq_ioctl_set_client_pool+0x214/0x260
snd_seq_ioctl+0x119/0x540
__x64_sys_ioctl+0xd1/0x120
do_syscall_64+0xbb/0x2f0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
A second run with larger pools hit the same target path:
signal: resize iteration=32 target_pool=64 exceeded 250ms
(elapsed=251ms)
diagnostic: resize_tid=663 wchan=snd_seq_pool_done
diagnostic: resize_tid=663 stack=
snd_seq_pool_done+0x5b/0x140
snd_seq_pool_delete+0x7a/0x90
snd_seq_fifo_resize+0x193/0x1e0
snd_seq_ioctl_set_client_pool+0x214/0x260
snd_seq_ioctl+0x119/0x540
__x64_sys_ioctl+0xd1/0x120
do_syscall_64+0xbb/0x2f0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fixes:
|
||
|
Jaroslav Kysela
|
4276338ce8 |
ALSA: seq: oss: Serialize readq reset state with q->lock
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 49ce92d207820f588b0406add82f053decfbe5d9
Author: Cen Zhang <zzzccc427@gmail.com>
Date: Sun Jun 14 08:48:00 2026 +0800
ALSA: seq: oss: Serialize readq reset state with q->lock
snd_seq_oss_readq_clear() resets qlen, head, and tail without
q->lock even though the normal reader and producer paths serialize the
same ring state under that spinlock. A reset can therefore race
snd_seq_oss_readq_free() or snd_seq_oss_readq_put_event() and leave
stale records in the queue, drop freshly queued ones, or report the
wrong readiness after wakeup. KCSAN reports a data race between
snd_seq_oss_readq_clear() and snd_seq_oss_readq_free().
Take q->lock while clearing the ring and resetting input_time. Factor
the enqueue logic into a caller-locked helper so
snd_seq_oss_readq_put_timestamp() updates its suppression state under
the same lock instead of racing the reset path.
The buggy scenario involves two paths, with each column showing the
order within that path:
reset path: locked readq updater:
1. snd_seq_oss_reset() or 1. A reader or callback producer
release reaches takes q->lock on the same queue.
snd_seq_oss_readq_clear().
2. snd_seq_oss_readq_clear() 2. The updater tests or modifies
resets qlen, head, tail, qlen, head, and tail.
and input_time.
3. snd_seq_oss_readq_clear() 3. The updater completes its
wakes sleepers on read-modify-write sequence.
q->midi_sleep.
4. Without q->lock, the reset 4. The resulting ring state drives
can overlap the locked later reads and readiness.
update.
KCSAN reports:
BUG: KCSAN: data-race in snd_seq_oss_readq_clear /
snd_seq_oss_readq_free
write to 0xffff8881069fe608 of 4 bytes by task 120516 on cpu 0:
snd_seq_oss_readq_free+0x6c/0x80
snd_seq_oss_read+0xcb/0x250
odev_read+0x38/0x60
vfs_read+0xff/0x600
ksys_read+0xb4/0x140
__x64_sys_read+0x46/0x60
do_syscall_64+0xbb/0x2f0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff8881069fe608 of 4 bytes by task 120517 on cpu 1:
snd_seq_oss_readq_clear+0x1f/0x90
snd_seq_oss_reset+0xa7/0xf0
snd_seq_oss_ioctl+0x6f6/0x7e0
odev_ioctl+0x56/0xc0
__x64_sys_ioctl+0xd1/0x120
do_syscall_64+0xbb/0x2f0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000001 -> 0x00000000
Fixes:
|
||
|
Jaroslav Kysela
|
1499166354 |
ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 69b4141b428bcf2cf7a863950c0d6e5c5ae89ac1 Author: Guangshuo Li <lgs201920130244@gmail.com> Date: Thu Jun 4 20:55:20 2026 +0800 ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO The PLL lock failure path in adau1372_set_power() unwinds by putting the regmap back in cache-only mode, asserting the optional power-down GPIO and disabling mclk. adau1372_enable_pll() enables CLK_CTRL.PLL_EN before polling the PLL lock bit. If the lock fails on a board without a power-down GPIO, the error path disables mclk and returns an error, but leaves PLL_EN set in the hardware register. The normal power-off path already handles the no-GPIO case by explicitly clearing PLL_EN. Mirror that cleanup in the PLL lock failure path and clear PLL_EN while the regmap is still live, before switching it back to cache-only mode. Fixes: bfe6a264effc ("ASoC: adau1372: Fix clock leak on PLL lock failure") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Link: https://patch.msgid.link/20260604125520.1428905-1-lgs201920130244@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
3b4964f67a |
ALSA: seq: Fix kernel heap address leak in bounce_error_event()
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit efc86691e4d8083d9e380ea95042c2cf679f65fd
Author: HanQuan <eilaimemedsnaimel@gmail.com>
Date: Fri Jun 12 10:32:22 2026 +0000
ALSA: seq: Fix kernel heap address leak in bounce_error_event()
The comment above bounce_error_event() documents that user clients
should receive SNDRV_SEQ_EVENT_BOUNCE with the original event embedded
as variable-length data, while kernel clients should receive
SNDRV_SEQ_EVENT_KERNEL_ERROR with a quoted kernel pointer.
However, the implementation unconditionally uses
SNDRV_SEQ_EVENT_KERNEL_ERROR with data.quote.event set to the raw
struct snd_seq_event pointer for all clients. When a bounce error
event is delivered to a USER_CLIENT via snd_seq_read(), the kernel
heap address in data.quote.event is exposed to userspace through
copy_to_user() in the fixed-length branch.
This is a distinct leak path from the one addressed by commit
705dd6dcbc0e ("ALSA: seq: Clear variable event pointer on read"),
which sanitizes data.ext.ptr in the variable-length branch of
snd_seq_read(). The bounce_error_event() leak uses fixed-length
events that take the else branch where no sanitization occurs.
Differentiate the bounce event by client type. For USER_CLIENT,
send SNDRV_SEQ_EVENT_BOUNCE with SNDRV_SEQ_EVENT_LENGTH_VARIABLE
and data.ext pointing to the original event. The variable-length
path in snd_seq_event_dup() copies the event data into chained
cells, and snd_seq_expand_var_event() copies only the content --
never the pointer -- to userspace. For KERNEL_CLIENT, keep the
existing SNDRV_SEQ_EVENT_KERNEL_ERROR behavior with the quoted
pointer.
Fixes:
|
||
|
Jaroslav Kysela
|
e90a1753fa |
ALSA: usb-audio: qcom: Guard sideband endpoint removal
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 2773023abb381e36ce02d364022d901f6f7a416d Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Thu Jun 11 10:57:22 2026 -0300 ALSA: usb-audio: qcom: Guard sideband endpoint removal qmi_stop_session() conditionally looks up the cached data and sync endpoints, but removes each endpoint unconditionally. The data endpoint is always present for an active offload stream, while the sync endpoint is optional. When no sync endpoint exists, ep still refers to the data endpoint and the code attempts to remove that endpoint a second time. The current sideband implementation rejects the duplicate removal, but the teardown path should not pass an unrelated endpoint for an absent sync endpoint. Only look up and remove an endpoint when its cached pipe exists, check the lookup result, and clear the cached pipe after handling it. This matches the normal stream-disable path. Fixes: 326bbc348298 ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260611-alsa-usb-qcom-guard-sideband-endpoint-removal-v1-1-00e73787c156@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
d24b8e8f69 |
ASoC: topology: Check PCM and DAI name strings before use
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit b7e44d1986d6671342c19b82192189ca5db5dab7 Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Thu Jun 4 00:10:58 2026 -0300 ASoC: topology: Check PCM and DAI name strings before use Topology objects store several PCM and DAI names in fixed-size UAPI arrays. Other topology parser paths validate these fields with bounded strnlen() checks before using them as C strings, but the PCM and DAI paths still pass some fixed-size arrays directly to strlen(), devm_kstrdup(), DAI lookup, and diagnostic prints. A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream capability name can therefore make the parser read past the end of the fixed-size field. Reject unterminated PCM and DAI name fields before consuming them as C strings. Fixes: |
||
|
Jaroslav Kysela
|
a543d500cd |
ASoC: tegra: tegra210_ahub: Validate written enum value
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 1d8aabb413b5638670dfd1162169edc0ba276a2e
Author: HyeongJun An <sammiee5311@gmail.com>
Date: Tue Jun 9 21:43:16 2026 +0900
ASoC: tegra: tegra210_ahub: Validate written enum value
tegra_ahub_put_value_enum() reads e->values[item[0]] before
checking whether item[0] is within the enum item range. The existing
check therefore happens too late to prevent an out-of-range read of the
values array.
Move the check before the array access.
Fixes:
|
||
|
Jaroslav Kysela
|
9364842ab4 |
ASoC: fsl: fsl_audmix: Validate written enum values
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 3cd17e4e2871114d5579fa7bc8da66faf7fc1930
Author: HyeongJun An <sammiee5311@gmail.com>
Date: Tue Jun 9 21:43:15 2026 +0900
ASoC: fsl: fsl_audmix: Validate written enum values
fsl_audmix_put_mix_clk_src() and fsl_audmix_put_out_src()
convert the user-provided enum item with snd_soc_enum_item_to_val()
before checking whether the item is within the enum's item count.
The generic snd_soc_put_enum_double() helper performs that
validation, but these callbacks use the converted value first: the
clock-source path tests it with BIT(), and the output-source path
indexes the prms transition table with it.
Reject out-of-range enum items before converting them.
Fixes:
|
||
|
Jaroslav Kysela
|
fe77006e03 |
ASoC: meson: aiu: Validate written enum values
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit d65adf85477247be04ac86886f8edfaa047b5d4a Author: HyeongJun An <sammiee5311@gmail.com> Date: Tue Jun 9 21:43:14 2026 +0900 ASoC: meson: aiu: Validate written enum values The AIU HDMI and internal codec mux put callbacks use the written enum value with snd_soc_enum_item_to_val() before checking whether the value is valid for the enumeration. Reject out-of-range values before converting the enum item, matching the validation already done by the G12A HDMI and internal codec mux controls. Fixes: |
||
|
Jaroslav Kysela
|
d62ccf6002 |
ASoC: codecs: hdac_hdmi: Validate written enum value
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 0b08baeccdcf52fad328ad645f5b4fbee04eea34
Author: HyeongJun An <sammiee5311@gmail.com>
Date: Tue Jun 9 21:43:13 2026 +0900
ASoC: codecs: hdac_hdmi: Validate written enum value
hdac_hdmi_set_pin_port_mux() uses the written enum value to index the
texts array before calling snd_soc_dapm_put_enum_double(), which validates
that the value is within the enum item range.
An out-of-range value can therefore make the driver read past the texts
array before the helper rejects the write. Move the lookup after the helper
has accepted the value.
Fixes:
|
||
|
Jaroslav Kysela
|
88654e224c |
ASoC: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 999ec4c29d73ac85b639a31bbc85ad2ec00eb9d7 Author: Arnd Bergmann <arnd@arndb.de> Date: Thu Jun 11 15:23:06 2026 +0200 ASoC: SOF: Intel: hda-sdw-bpt: select SND_SOF_SOF_HDA_SDW_BPT properly When SND_SOC_SOF_INTEL_LNL is set, SND_SOF_SOF_HDA_SDW_BPT must also be enabled, in order to let the soundwire support call into it. However, there are configurations with SND_SOF_SOF_HDA_SDW_BPT=m and SND_SOF_SOF_HDA_SDW_BPT=m but SOUNDWIRE_INTEL=y, which still lead to a link failure: aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_ace2x_bpt_wait': intel_ace2x.c:(.text+0xfc8): undefined reference to `hda_sdw_bpt_wait' aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_ace2x_bpt_send_async': intel_ace2x.c:(.text+0x1ff8): undefined reference to `hda_sdw_bpt_get_buf_size_alignment' Address this by moving the 'select SND_SOF_SOF_HDA_SDW_BPT' into SND_SOC_SOF_HDA_GENERIC. Fixes: 614d416dd8ae ("ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260611132310.137688-2-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
e00e1c29c9 |
ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from SND_SOC_SOF_HDA_GENERIC=y
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 67805f57e5b1a8589f89bd48936c65cbbaeec300 Author: Arnd Bergmann <arnd@arndb.de> Date: Thu Jun 11 15:23:05 2026 +0200 ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from SND_SOC_SOF_HDA_GENERIC=y When SND_SOC_SOF_HDA_GENERIC=y but SND_SOC_SOF_INTEL_SOUNDWIRE=m, the SND_SOC_SDW_UTILS is also set to =m even though there is a direct link dependency from the hda.c: aarch64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_machine_select': hda.c:(.text+0x21ac): undefined reference to `codec_info_list' hda.c:(.text+0x241c): undefined reference to `asoc_sdw_get_dai_type' hda.c:(.text+0x25b4): undefined reference to `asoc_sdw_get_codec_info_list_count' hda.c:(.text+0x25d8): undefined reference to `asoc_sdw_get_codec_info_list_count' Change this the same way as the other related 'select' statements to allow linking against it. Fixes: 2b4d53eb5cf3 ("ASoC: SOF: Intel: select SND_SOC_SDW_UTILS in SND_SOC_SOF_HDA_GENERIC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260611132310.137688-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
6af31023e6 |
ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 3073eb1f1143deabbda6a043238ab9d99672e7c8 Author: Richard Fitzgerald <rf@opensource.cirrus.com> Date: Thu Jun 11 16:12:34 2026 +0100 ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer() In cs35l56_cal_data_debugfs_write() fix the if statement that checks for error return to only check for negative values. Reported by Sashiko: simple_write_to_buffer() returns the positive number of bytes copied on success. Since the condition returns immediately on any non-zero value, is it possible that the written calibration data is discarded and cs35l56_stash_calibration() is never called? Fixes: f7097161e94c ("ASoC: cs35l56: Add common code for factory calibration") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260610093432.557375-1-rf%40opensource.cirrus.com Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260611151234.1111153-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
c392373d6b |
ASoC: cs35l56: Fix possible uninitialized value in cs35l56_spi_system_reset()
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 007699d278a655871b07d45a1268761260d03124 Author: Richard Fitzgerald <rf@opensource.cirrus.com> Date: Thu Jun 11 14:22:21 2026 +0100 ASoC: cs35l56: Fix possible uninitialized value in cs35l56_spi_system_reset() In cs35l56_spi_system_reset() initialize val to zero before using it in the read_poll_timeout(). This prevents testing an uninitialized value if the regmap_read_bypassed() returns an error. Read errors are intentionally ignored during this loop because the device is resetting (though SPI can't really detect that so shouldn't fail because of that, it's safer to ignore errors and keep polling). Because of this, val must be initialized to something in case the first read fails. The polling loop is looking for a non-zero value, so initializing val to 0 will ensure that the loop continues until a valid state is read from the device or it times out. Fixes: 769c1b79295c ("ASoC: cs35l56: Prevent races when soft-resetting using SPI control") Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260611132221.1100497-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
a113ceb30d |
ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 53cebeb017164254cde5e31c94d8deef9e4fff97
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Wed Jun 10 11:55:56 2026 +0100
ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails
In cs35l56_system_suspend() re-enable the parent IRQ if the call to
pm_runtime_force_suspend() returns an error.
Fixes:
|
||
|
Jaroslav Kysela
|
6131462193 |
ASoC: codecs: aw88261: fix incorrect masks for boost regs
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 79c053a1ff9d3ab31cefbc791e8d7816ba830491
Author: Val Packett <val@packett.cool>
Date: Fri May 29 17:05:13 2026 -0300
ASoC: codecs: aw88261: fix incorrect masks for boost regs
The boost-related register fields used in aw88261_reg_force_set use the
exact same definitions as the rest of the fields, where the mask must be
inverted when passing it to regmap_update_bits, but they weren't
inverted here.
Fixes:
|
||
|
Jaroslav Kysela
|
1d61c6ad98 |
ASoC: sma1307: Fix uevent string leaks in fault worker
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit a750ca72af72dde9744468fdca6eda0b698a1cfc Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Tue Jun 9 09:03:56 2026 -0300 ASoC: sma1307: Fix uevent string leaks in fault worker sma1307_check_fault_worker() stores dynamically allocated uevent strings in envp[0]. Several fault conditions are checked in sequence, so a later fault can overwrite envp[0] before the final kfree() and leak the previous allocation. The same flow can leave an OT1 volume entry in envp[1] while envp[0] has been overwritten by a later non-OT1 fault, causing an inconsistent uevent payload. Use static STATUS strings and a stack buffer for the optional VOLUME entry. This removes the allocations from the worker and keeps VOLUME tied only to the OT1 events that produce it. Fixes: 576c57e6b4c1 ("ASoC: sma1307: Add driver for Iron Device SMA1307") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260609-asoc-sma1307-uevent-leak-v1-1-cd7f5b062ab7@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
55f0dc177b |
ALSA: aloop: Drop superfluous break
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 123fd13f35ccaf7d2b98f5a8cc6c8a3de378568d Author: Takashi Iwai <tiwai@suse.de> Date: Tue Jun 9 09:49:04 2026 +0200 ALSA: aloop: Drop superfluous break At converting the spinlock to guard(), a break statement was put in the scoped_guard block in loopback_jiffies_timer_function(), but it's obviously superfluous (although it's harmless). Better to drop it for avoiding confusion. Fixes: 1ef2cb6b29c2 ("ALSA: aloop: Use guard() for spin locks") Link: https://patch.msgid.link/20260609074907.726593-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
b20d49ac04 |
ASoC: amd: acp-sdw-sof: Bound DAI link iteration
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 4d992e63f52d58f52b724606c60ae7b37a1c582f
Author: Aaron Ma <aaron.ma@canonical.com>
Date: Thu May 28 16:21:10 2026 +0800
ASoC: amd: acp-sdw-sof: Bound DAI link iteration
create_sdw_dailinks() walks sof_dais until it finds an entry with
initialised cleared, but sof_dais is allocated with exactly num_ends
entries. If all entries are initialised, the loop reads past the end of
the array.
Pass the allocated entry count to create_sdw_dailinks() and stop before
reading past the array.
Fixes:
|
||
|
Jaroslav Kysela
|
fca85a45b1 |
ASoC: amd: acp-sdw-legacy: Bound DAI link iteration
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit d49ecdf327cc91062d2f80996a163cf65fda1e60 Author: Aaron Ma <aaron.ma@canonical.com> Date: Thu May 28 16:21:09 2026 +0800 ASoC: amd: acp-sdw-legacy: Bound DAI link iteration create_sdw_dailinks() walks soc_dais until it finds an entry with initialised cleared, but soc_dais is allocated with exactly num_ends entries. If all entries are initialised, the loop reads past the end of the array. This was reported by KASAN: BUG: KASAN: slab-out-of-bounds in mc_probe+0x26b3/0x2774 [snd_acp_sdw_legacy_mach] Read of size 1 Pass the allocated entry count to create_sdw_dailinks() and stop before reading past the array. Fixes: 2981d9b0789c ("ASoC: amd: acp: add soundwire machine driver for legacy stack") Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Link: https://patch.msgid.link/20260528082110.915549-1-aaron.ma@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
a68f4d8031 |
ALSA: seq: Clear variable event pointer on read
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 705dd6dcbc0ea87351c660c1a6443f85f1001c76
Author: Kyle Zeng <kylebot@openai.com>
Date: Sat Jun 6 17:41:29 2026 -0700
ALSA: seq: Clear variable event pointer on read
snd_seq_read() copies a queued variable-length event header to userspace
before expanding the payload. Queued variable-length events use
SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first
extension cell.
The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the
copy, but it leaves data.ext.ptr untouched. A userspace sequencer client
can therefore write a direct variable event to itself and read back the
extension-cell kernel address from the returned header.
Clear the temporary header pointer before copy_to_user(). The original
queued event remains unchanged and is still passed to
snd_seq_expand_var_event(), so payload expansion keeps using the
internal chain.
Fixes:
|
||
|
Jaroslav Kysela
|
c078715dd8 |
ALSA: seq: Fix partial userptr event expansion
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 2b7bd6f548292aec92a386deebe62324d21d62a9
Author: HyeongJun An <sammiee5311@gmail.com>
Date: Sat Jun 6 13:09:13 2026 +0900
ALSA: seq: Fix partial userptr event expansion
snd_seq_expand_var_event_at() clamps the number of bytes to copy to the
remaining variable-event length, but passes the original buffer size to
expand_var_event().
For SNDRV_SEQ_EXT_USRPTR events, expand_var_event() copies exactly the
size argument from userspace. On the final chunk, when the remaining
event data is shorter than the caller's buffer, this can read past the
declared event data and can spuriously fail with -EFAULT if the extra
bytes cross an unmapped page.
Pass the clamped length instead. The chained and kernel-backed paths
already reclamp in dump_var_event(), but the user-pointer path handles
the size directly.
Fixes:
|
||
|
Jaroslav Kysela
|
2c884a9e42 |
ALSA: hda: fix Kconfig dependency of HD Audio PCI
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 1516134cb65526aba5319bb446c296fc8a192f84 Author: Oliver Hartkopp <socketcan@hartkopp.net> Date: Fri May 29 17:23:59 2026 +0200 ALSA: hda: fix Kconfig dependency of HD Audio PCI With commit 2d9223d2d64c ("ALSA: hda: Move controller drivers into sound/hda/controllers directory") the HD Audio drivers have been moved from linux/sound/pci/hda to linux/sound/hda. But the Kconfig dependency for SND_HDA_INTEL stayed on SND_PCI instead of depending on PCI directly. To make the "HD Audio PCI" configuration entry visible it is currently needed to enable "PCI sound devices" although no PCI device in the submenu needs to be selected. Make SND_HDA_INTEL directly depending on hardware/architecture like the other entries in this Kconfig. Fixes: 2d9223d2d64c ("ALSA: hda: Move controller drivers into sound/hda/controllers directory") Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://patch.msgid.link/20260529-hda-kconfig-v1-1-4a2c6a0efd56@hartkopp.net Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
a043ce5cf2 |
ALSA: usb-audio: qcom: Initialize offload control return value
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 2b5632d72fca0841bea283da2e3a478d24118508 Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Fri Jun 5 01:14:40 2026 -0300 ALSA: usb-audio: qcom: Initialize offload control return value snd_usb_offload_create_ctl() returns ret after walking the USB PCM list, but ret is only assigned after a playback stream passes the endpoint and PCM-index filters. If all playback streams are skipped, for example because there is no playback endpoint or because all PCM indexes exceed the 0xff control range, the function returns an uninitialized stack value. Initialize ret to 0 so the no-control-created path returns deterministic success, while preserving the existing negative error return when snd_ctl_add() fails. Fixes: a67656f011d1 ("ALSA: usb-audio: qcom: Add USB offload route kcontrol") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260605-alsa-usb-qcom-offload-ret-init-v1-1-dc72fcc4bd3b@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
7dc5815c6b |
ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit c0758279367e9d82eb7d7b4959718d7d32e96b7d
Author: John Madieu <john.madieu.xa@bp.renesas.com>
Date: Mon May 25 11:02:14 2026 +0000
ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble
RSND_SOC_MASK was defined as (0xFF << 4), spanning bits 4-11. This is
wider than needed since only nibble B (bits 7:4) is used for SoC
identifiers. Narrow it to (0xF << 4) to match the intended single-nibble
allocation and prevent overlap with bits 8-11 which will be used by
upcoming RZ series flags.
No functional change, since the only current user (RSND_SOC_E) fits
within a single nibble.
Fixes:
|
||
|
Jaroslav Kysela
|
9b8f10e5f4 |
ALSA: seq: midi: Serialize output teardown with event_input
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit ef7607ab1c8adc6258fb1b27d08e26aecdc18a58
Author: Zhang Cen <rollkingzzc@gmail.com>
Date: Wed May 27 14:29:48 2026 +0800
ALSA: seq: midi: Serialize output teardown with event_input
event_process_midi() borrows msynth->output_rfile.output and then
passes the substream to dump_midi() and snd_rawmidi_kernel_write()
without synchronizing with the output open/close transition.
midisynth_use() also publishes output_rfile before
snd_rawmidi_output_params() has finished.
The last midisynth_unuse() can therefore release the same rawmidi file
and free substream->runtime before snd_rawmidi_kernel_write1() takes
its runtime buffer reference. That leaves the event_input path using a
stale substream or runtime and can end in a NULL-deref or use-after-free.
Fix this with two pieces of synchronization. Keep a short IRQ-safe
spinlock only for publishing or clearing output_rfile and for pairing
the output snapshot with an snd_use_lock_t reference. Once
event_process_midi() has taken that in-flight reference, it drops the
spinlock before calling snd_seq_dump_var_event(), dump_midi(), or
snd_rawmidi_kernel_write(). midisynth_unuse() now detaches the visible
rawmidi file under the same spinlock, waits for the in-flight writers
to drain, and only then drains and releases the saved file.
midisynth_use() likewise opens into a local snd_rawmidi_file and
publishes it only after snd_rawmidi_output_params() succeeds.
The buggy scenario involves two paths, with each column showing the
order within that path:
event_input path: last unuse path:
1. event_process_midi() snapshots 1. midisynth_unuse() starts
output_rfile.output. tearing down output_rfile.
2. dump_midi() reaches 2. snd_rawmidi_kernel_release()
snd_rawmidi_kernel_write() closes the output file.
before runtime is pinned. 3. close_substream() frees
3. The callback keeps using substream->runtime.
the borrowed substream.
Validation reproduced this kernel report:
KASAN null-ptr-deref in snd_rawmidi_kernel_write1+0x56/0x360
RIP: 0033:0x7fde7dd0837f
RIP: 0010:snd_rawmidi_kernel_write1+0x56/0x360
Fixes:
|
||
|
Jaroslav Kysela
|
e6a48b9dd1 |
ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 7c349b4f2a603202fb8c363bd2774a22ac2fddf3
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue May 26 17:28:41 2026 +0200
ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data
The OSS sequencer processes the input MIDI bytes into a sequencer
event to be dispatched later (in snd_seq_oss_midi_putc() called from
snd_seq_oss_process_event()). When it's a SysEx data, the event
record contains data.ext.ptr pointer to the original SysEx bytes, and
the referred data is copied into the pool afterwards at dispatching.
The problem is that, if the sequencer port gets closed concurrently
before the dispatch, the OSS sequencer core also releases the
resources (in snd_seq_oss_midi_check_exit_port()), while the pending
event may hold a stale pointer, eventually leading to a UAF at a later
dispatch.
Fortunately, there is already a refcounting mechanism (snd_use_lock_t)
for the OSS MIDI device access, and for addressing the issue above, we
just need to extend the refcount until the event gets dispatched.
This patch extends snd_seq_oss_process_event() to give back the
refcount object, which is in turn released after calling the sequencer
dispatcher with the given event in the caller side.
According to the original report, KASAN report as below:
KASAN slab-use-after-free in snd_seq_event_dup+0x40c/0x470
RIP: 0033:0x7f2cb66a6340
Read of size 6
Call trace:
dump_stack_lvl+0x73/0xb0 (?:?)
print_report+0xd1/0x650 (?:?)
srso_alias_return_thunk+0x5/0xfbef5 (?:?)
__virt_addr_valid+0x1a7/0x340 (?:?)
kasan_complete_mode_report_info+0x64/0x200 (?:?)
kasan_report+0xf7/0x130 (?:?)
snd_seq_event_dup+0x40c/0x470 (?:?)
kasan_check_range+0x10c/0x1c0 (?:?)
__asan_memcpy+0x27/0x70 (?:?)
snd_seq_event_dup+0x9/0x470 (?:?)
snd_seq_client_enqueue_event+0x139/0x240 (?:?)
_raw_spin_unlock_irqrestore+0x4b/0x60 (?:?)
snd_seq_kernel_client_enqueue+0x102/0x120 (?:?)
snd_seq_oss_write+0x416/0x4e0 (?:?)
apparmor_file_permission+0x20/0x30 (?:?)
odev_write+0x3b/0x60 (?:?)
vfs_write+0x1ce/0x850 (?:?)
lock_release+0xc8/0x2a0 (?:?)
__kasan_check_write+0x18/0x20 (?:?)
__mutex_unlock_slowpath+0x129/0x510 (?:?)
ksys_write+0xe1/0x180 (?:?)
mutex_unlock+0x16/0x20 (?:?)
odev_ioctl+0x65/0xc0 (?:?)
__x64_sys_write+0x46/0x60 (?:?)
x64_sys_call+0x7d/0x20d0 (?:?)
do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87)
entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)
Fixes:
|
||
|
Jaroslav Kysela
|
d89b58336b |
ALSA: xen-front: Connect event channel after stream prepare
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 3624f0bd4af15a820b1bd88b489980fa9fd61b7a
Author: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Date: Tue May 26 09:48:27 2026 -0300
ALSA: xen-front: Connect event channel after stream prepare
The request channel must be connected from ALSA .open(), because hw-rule
queries and the stream open request use it. The event channel is
different: XENSND_EVT_CUR_POS handling uses ALSA runtime buffer and
period geometry, and the corresponding Xen stream parameters are not
submitted to the backend until .prepare() sends XENSND_OP_OPEN.
Currently .open() connects both channels. A backend current-position
event, or a stale event queued for an earlier stream instance, can
therefore reach xen_snd_front_alsa_handle_cur_pos() before
runtime->buffer_size and runtime->period_size are valid.
Add a per-channel connection helper, connect only the request channel in
.open(), connect the event channel after a successful stream prepare,
and disconnect it before stream close/free. Re-check the event-channel
state after taking ring_io_lock so disconnecting the event channel
synchronizes against a threaded IRQ that passed the initial lockless
state test. Keep defensive runtime geometry checks in the position
handler.
Fixes:
|
||
|
Jaroslav Kysela
|
4245346923 |
ALSA: xen-front: Reset event channel state on stream clear
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 9cd81152373c560b8aa8299b0705c4db82b103b7
Author: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Date: Tue May 26 09:48:26 2026 -0300
ALSA: xen-front: Reset event channel state on stream clear
xen_snd_front_evtchnl_pair_clear() resets evt_next_id for both
channels. That is correct for the request channel, where evt_next_id is
used to allocate the next request id. It is wrong for the event channel:
incoming events are validated against evt_id, and evt_id is incremented
by evtchnl_interrupt_evt().
This leaves the expected event id from the previous stream instance. A
backend that restarts event ids for a reopened stream can then have valid
current-position events dropped until the stale frontend id catches up.
Reset evt_id for the event channel. Also advance the event-page consumer
to the current producer while clearing the stream, so obsolete events
queued for the previous stream instance are not delivered to the next
ALSA runtime.
Fixes:
|
||
|
Jaroslav Kysela
|
330ed7ff9c |
ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 8468c8aafe8b5807e5acba2f8aa96d0b3ce0c248
Author: Chancel Liu <chancel.liu@nxp.com>
Date: Thu May 7 10:36:52 2026 +0900
ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts
Currently dapm_find_widget() manually constructs a prefixed widget name
based on the provided DAPM context and compares it using strcmp(). This
happens to work in most cases because callers usually know which DAPM
context the target widget belongs to and pass in the matching DAPM
context.
However, this assumption breaks when search_other_contexts is enabled.
In such cases, callers may intentionally pass a different DAPM context,
while searching for a widget that actually belongs to another DAPM
context.
For example, when searching for a "DAC" widget, the widget belongs to
the codec DAPM and be registered with a codec prefix, while the caller
passes card->dapm and intends to search across all DAPM contexts. The
current implementation incorrectly applies the caller card DAPM causing
the lookup to fail even though the widget exists on the card.
Improve the matching strategy to support both use cases:
1. When the caller provides a fully qualified name with prefix, perform
exact string matching. This preserves the ability to use prefixes for
disambiguation.
2. When the caller provides a bare widget name without prefix, try exact
matching first, then fall back to prefix-stripped comparison using
snd_soc_dapm_widget_name_cmp().
To determine whether the pin name includes a prefix, a new helper
function snd_soc_dapm_pin_has_prefix() is introduced. It checks if the
pin name starts with any known component prefix on the card.
This fixes widget lookup failures when searching across different DAPM
contexts while maintaining backward compatibility for explicitly
prefixed lookups.
Fixes:
|
||
|
Jaroslav Kysela
|
ec0ffc59db |
ASoC: mediatek: mt8189: Fix probe resource cleanup
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 5404599c3292a12dfc6a3b604cebb5d51064f553 Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Thu May 14 10:52:35 2026 -0300 ASoC: mediatek: mt8189: Fix probe resource cleanup The MT8189 AFE probe assigns reserved memory with of_reserved_mem_device_init(), but only releases that assignment from .remove(). If probe fails after the reserved memory has been assigned, the assignment record is left behind. The probe path also uses pm_runtime_get_sync() without checking its return value. If runtime resume fails, pm_runtime_get_sync() leaves the usage count incremented and the driver continues initialization without the device being resumed. Use pm_runtime_resume_and_get() so resume errors abort probe without leaking a PM usage count. Finally, component registration failure currently jumps to a label that drops a runtime PM reference even though the temporary probe reference was already released. Return the component registration error directly, and do not drop an unmatched PM reference from .remove(). Fixes: 7eb153585598 ("ASoC: mediatek: mt8189: add platform driver") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260514-asoc-mt8189-probe-cleanup-v1-1-ded733363281@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
994bbf767c |
ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID 17aa:38a7
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit d35dfb6329accfe1cfa0b57e35214b5cbbe0f9ae Author: Damien Laine <damien.laine@gmail.com> Date: Sun Jul 12 23:37:08 2026 +0200 ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID 17aa:38a7 Some units of the Lenovo Legion Pro 7 16ARX8H (82WS) report codec subsystem ID 17aa:38a7 instead of 17aa:38a8. Since only 38a8 has a codec SSID quirk, these machines fall through to the PCI SSID match 17aa:386f (Legion Pro 7i 16IAX7) and get ALC287_FIXUP_CS35L41_I2C_2, which probes the Cirrus amplifiers of the Intel variant. The TI TAS2781 amplifier (ACPI TIAS2781:00) present on this AMD variant is never bound and the internal speakers remain silent. Add a codec SSID quirk for 17aa:38a7 pointing to ALC287_FIXUP_TAS2781_I2C, mirroring the existing 38a8 entry. Tested on a Legion Pro 7 16ARX8H (82WS, BIOS LPCN62WW): with the codec SSID overridden to 17aa:38a8 via the HDA patch loader, the TAS2781 amplifier binds and the internal speakers work. Cc: <stable@vger.kernel.org> Signed-off-by: Damien Laine <damien.laine@gmail.com> Link: https://patch.msgid.link/20260712213708.1835469-1-damien.laine@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
9835d79f4e |
ALSA: hda: Fix cached processing coefficient verbs
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit f67be28fdf8b5d31ac1cc1152bb17250f9f8f513
Author: Xu Rao <raoxu@uniontech.com>
Date: Tue Jul 7 21:24:19 2026 +0800
ALSA: hda: Fix cached processing coefficient verbs
Intel HD Audio defines Coefficient Index and Processing Coefficient as
separate audio widget controls in the Audio Widget Verb Definitions:
Coefficient Index selects the coefficient slot, while Processing
Coefficient accesses the value at the selected slot.
hda_reg_read_coef() selects the slot with AC_VERB_SET_COEF_INDEX, but
then uses AC_VERB_GET_COEF_INDEX for the value read. That reads back the
selected index instead of the coefficient value. hda_reg_write_coef()
has the same issue and builds the value write from AC_VERB_GET_COEF_INDEX
instead of AC_VERB_SET_PROC_COEF.
This only affects the regmap coefficient cache path used by codecs that
set codec->cache_coef. Direct coefficient helpers already use the normal
SET_COEF_INDEX followed by GET_PROC_COEF or SET_PROC_COEF sequence, which
is likely why this has not been noticed widely.
Use AC_VERB_GET_PROC_COEF for cached coefficient reads and
AC_VERB_SET_PROC_COEF for cached coefficient writes.
Fixes:
|
||
|
Jaroslav Kysela
|
81a6e23cb0 |
ALSA: hda: conexant: Remove mic bias threshold override
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit f52524da7084c1a54683ae9fbc73e93fff19dd64
Author: Zhang Heng <zhangheng@kylinos.cn>
Date: Mon Jul 13 18:03:29 2026 +0800
ALSA: hda: conexant: Remove mic bias threshold override
Remove the mic bias current comparator threshold override (NID 0x1c,
verb 0x320, value 0x010) from Conexant codec driver.
This override was originally intended to support volume up/down controls on
headsets with inline remote controls, but it causes microphone detection
failures on some headsets with impedance less than 1k ohm.
After consulting with the vendor's engineers, it was confirmed that this
setting is board-specific and should be handled by BIOS/firmware rather
than the generic codec driver, especially since inline remote support
is not currently implemented.
Fixes:
|
||
|
Jaroslav Kysela
|
198ba863fb |
ALSA: hda/realtek: Add quirk for TongFang X6xx45xU
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit d595255241e5fec0c94adeebf2565524398e37c5 Author: Eckhart Mohr <e.mohr@tuxedocomputers.com> Date: Wed Jul 8 15:21:06 2026 +0200 ALSA: hda/realtek: Add quirk for TongFang X6xx45xU 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/20260708132135.102680-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
bd23b53a89 |
ALSA: doc: usb-audio: Add doc for QUIRK_FLAG_IFB_SILENCE_ON_EMPTY
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 06363f96e3d6b54ff7b5d2ce85cab95bd5e874b0 Author: Rong Zhang <i@rong.moe> Date: Wed May 27 01:49:23 2026 +0800 ALSA: doc: usb-audio: Add doc for QUIRK_FLAG_IFB_SILENCE_ON_EMPTY QUIRK_FLAG_IFB_SILENCE_ON_EMPTY was introduced into usb-audio before without appropriate documentation, so add it. Fixes: a23812004228 ("ALSA: usb-audio: add IFB_SILENCE_ON_EMPTY quirk for Behringer Flow 8") Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260527-uac-quirk-get-cur-vol-v1-1-e9362b712e5e@rong.moe Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
dda5973b8d |
ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful writes
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit a440c17869ecd71da0f295b62868fc742d09a8ba
Author: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Date: Sun Apr 19 17:30:32 2026 -0300
ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful writes
snd_us16x08_comp_put() and snd_us16x08_eq_put() update their
software stores before sending the USB write. If the transfer
fails, later get callbacks report a value the hardware never
accepted.
Build the outgoing message from the current store plus the
pending value, then commit the store only after a successful
write.
Fixes:
|
||
|
Jaroslav Kysela
|
dd08a325ef |
ALSA: usb-audio: Update Babyface Pro control caches only after successful writes
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit d8f802ccf1fdbeb89d62748d6a0d0fbd442c8127
Author: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Date: Wed Apr 29 10:20:02 2026 -0300
ALSA: usb-audio: Update Babyface Pro control caches only after successful writes
snd_bbfpro_ctl_put() and snd_bbfpro_vol_put()
cache the requested packed control state in
kcontrol->private_value before issuing the USB write.
Their get and resume paths use that cached value directly,
so a failed write can leave the driver reporting and later
replaying a setting the hardware never accepted.
Update the cached state only after a successful USB write.
Fixes:
|
||
|
Jaroslav Kysela
|
355ebba4f6 |
ALSA: usb-audio: Roll back quirk control caches on write errors
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit 6380957fa24251856a532e48a46a4dc3d1ae26b6 Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Wed Apr 29 10:20:01 2026 -0300 ALSA: usb-audio: Roll back quirk control caches on write errors Several mixer quirk callbacks cache the requested control value in kcontrol->private_value before issuing a single vendor or class write. Their paired get and resume paths consume that cache directly, so a failed write currently leaves software state changed even though the update did not succeed. That can make later reads report a value the device never accepted and can replay the stale cache on resume. Restore the previous cached value on failure in the Audigy2NX LED, Emu0204 channel switch, Xonar U1 output switch, Native Instruments controls, FTU effect program switch, and Sound Blaster E1 input source switch. Fixes: |
||
|
Jaroslav Kysela
|
94427374ba |
ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch put callbacks
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 3c06aec8abda6ba068b58a8b7119cdb2a48456b1
Author: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Date: Sun Apr 19 17:30:31 2026 -0300
ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch put callbacks
Several US-16x08 mixer put callbacks log failed control URBs but
still return success to userspace. That hides device write failures
even though the requested value was not applied.
Return the negative write error instead in the route, master, bus,
channel, and EQ switch put callbacks.
Fixes:
|
||
|
Jaroslav Kysela
|
11de262cc9 |
ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()
JIRA: https://issues.redhat.com/browse/RHEL-193253
commit 0f25cf1f02e3dba626791d949c759a48c0a44996
Author: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Date: Sun Apr 19 17:30:30 2026 -0300
ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()
scarlett_ctl_enum_put() ignores the return value from
snd_usb_set_cur_mix_value() and reports success whenever the
requested enum value differs from the current one.
If the SET_CUR request fails, the callback still returns success even
though neither the hardware state nor the cached mixer value changed.
Fixes:
|
||
|
Jaroslav Kysela
|
0150706371 |
ALSA: usb-audio: avoid kobject path lookup in DualSense match
JIRA: https://issues.redhat.com/browse/RHEL-193253 CVE: CVE-2026-64478 commit 7693c0cc415f3a16a7a3355f245474a5e661be4e Author: Darvell Long <contact@darvell.me> Date: Wed Jun 24 07:37:23 2026 -0700 ALSA: usb-audio: avoid kobject path lookup in DualSense match The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect. Fixes: 79d561c4ec04 ("ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5") Cc: <stable@vger.kernel.org> Assisted-by: Cute:gpt-5.5 Signed-off-by: Darvell Long <contact@darvell.me> Link: https://patch.msgid.link/20260624143723.2986353-1-contact@darvell.me Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
3aa552bbf9 |
ALSA: usb-audio: add IFB_SILENCE_ON_EMPTY quirk for Behringer Flow 8
JIRA: https://issues.redhat.com/browse/RHEL-193253 commit a23812004228d4b041a858b927db787a7ff80f50 Author: Gordon Chen <chengordon326@gmail.com> Date: Tue May 26 15:29:06 2026 +0800 ALSA: usb-audio: add IFB_SILENCE_ON_EMPTY quirk for Behringer Flow 8 The Behringer Flow 8 (1397:050c) is an 8-channel USB mixer that declares OUT EP 0x01 with implicit feedback from capture EP 0x81 via its UAC2 endpoint companion descriptor. After 5-35 minutes of continuous playback, the device occasionally returns a capture URB in which every iso_frame_desc has a non-zero status (-EXDEV bursts, visible as rate-limited "frame N active: -18" lines in dmesg from pcm.c). In that case snd_usb_handle_sync_urb() at endpoint.c counts bytes==0 and falls into the early "skip empty packets" return originally added for M-Audio Fast Track Ultra. As a result the playback EP loses its sole IFB-driven feeder and the OUT ring starves permanently: hw_ptr stops advancing while substream state remains RUNNING. Only USB re-enumeration recovers. Three independent ftrace captures (taken at the moment of stall via a userspace watchdog) consistently show: - 60-70 capture URB completions in the 70ms window before the marker - 0 retire_playback_urb / queue_pending_output_urbs / snd_usb_endpoint_implicit_feedback_sink calls - every usb_submit_urb in the window comes from snd_complete_urb+0x64e (capture self-resubmit), none from the queue_pending_output_urbs path Add a new opt-in quirk QUIRK_FLAG_IFB_SILENCE_ON_EMPTY: when set, the early return is skipped and we fall through to enqueue a packet_info whose packet_size[i] are all 0 (the existing loop already maps status!=0 packets to size 0). prepare_outbound_urb then emits a silence packet, the OUT ring keeps moving, and the device rides through the glitch. The default behaviour (early return) is preserved for all existing devices including M-Audio Fast Track Ultra. Only Flow 8 opts in here. Cc: stable@vger.kernel.org Signed-off-by: Gordon Chen <chengordon326@gmail.com> Link: https://patch.msgid.link/20260526072906.90106-1-chengordon326@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
dfac8046e7 |
ALSA: update RHEL kconfigs for 7.1 upstream code
JIRA: https://issues.redhat.com/browse/RHEL-183295 Upstream-status: RHEL-only Added configurations: Add common/generic:CONFIG_SND_SOC_WM_ADSP=n Add common/generic:CONFIG_SND_SOC_WM_ADSP_TEST=n Add common/generic/x86:CONFIG_SND_SOC_WM_ADSP=m Add common/generic:CONFIG_SND_SOC_UDA1380=n Add common/generic:CONFIG_SND_SOC_CS35L56_CAL_PERFORM_CTRL=n Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
9f8bb4f9e5 |
ASoC: sdw_utils: fix missing component_name for cs42l43 part_id 0x2A3B
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit c429fbea6174a7dd40c4215288589a50e8a33ff6 Author: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Date: Wed Jun 10 12:17:53 2026 +0800 ASoC: sdw_utils: fix missing component_name for cs42l43 part_id 0x2A3B commit 87a3f5c8ac20 ("ASoC: sdw_utils: cs42l43: allow spk component names to be combined") moved spk:cs42l43-spk generation from rtd_init() into the asoc_sdw_rtd_init() generic path by adding component_name to codec_info_list entries. However, only the 0x4243 cs42l43 entry was updated; the 0x2A3B entry (vendor_id 0x01fa, Cirrus Logic cs42l43 with sidecar bridge) was missed. Without component_name on the 0x2A3B dp6 DAI, asoc_sdw_rtd_init() never accumulates spk_components and never appends 'spk:cs42l43-spk' (or its sidecar alias 'spk:cs35l56-bridge') to card->components. The sof-soundwire UCM regex ' spk:([a-z0-9]+...)' then fails to match, causing WirePlumber to mark all HiFi profiles as unavailable=no and fall back to the Off profile — resulting in Dummy Output in GNOME. The existing sidecar redirect in asoc_sdw_rtd_init() already handles the SOC_SDW_SIDECAR_AMPS case: when component_name is 'cs42l43-spk' and sidecar amps are active, it substitutes 'cs35l56-bridge' into card->components, which matches the existing cs35l56-bridge.conf UCM file. Fixes: 87a3f5c8ac20 ("ASoC: sdw_utils: cs42l43: allow spk component names to be combined") Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Link: https://patch.msgid.link/20260610041753.1151088-1-acelan.kao@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
cbc4a6b468 |
ASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit e4c60a1d4b6ccc66aefb3789cd908d4f9482eefd Author: Kean Ren <rh_king@163.com> Date: Thu Jun 11 10:37:57 2026 +0800 ASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions sdca_dev_unregister_functions() iterates over all SDCA function descriptors and calls sdca_dev_unregister() on each func_dev without checking for NULL. When a function registration has failed partway through, or the device cleanup races with probe deferral, func_dev entries may be NULL, leading to a kernel oops: BUG: kernel NULL pointer dereference, address: 0000000000000040 RIP: 0010:device_del+0x1e/0x3e0 Call Trace: sdca_dev_unregister_functions+0x37/0x60 [snd_soc_sdca] release_nodes+0x35/0xb0 devres_release_all+0x90/0x100 device_unbind_cleanup+0xe/0x80 device_release_driver_internal+0x1c1/0x200 bus_remove_device+0xc6/0x130 device_del+0x161/0x3e0 device_unregister+0x17/0x60 sdw_delete_slave+0xb6/0xd0 [soundwire_bus] sdw_bus_master_delete+0x1e/0x50 [soundwire_bus] ... sof_probe_work+0x19/0x30 [snd_sof] This was observed on a Lenovo ThinkPad X1 Carbon G14 (Panther Lake) with the SOF audio driver probe failing due to missing Panther Lake firmware, causing the subsequent cleanup of SoundWire devices to trigger the crash. Fix this with three changes: 1) Add a NULL guard in sdca_dev_unregister() so that callers do not need to pre-validate the pointer (defense in depth). 2) In sdca_dev_unregister_functions(), skip NULL func_dev entries and clear func_dev to NULL after unregistration, making the function idempotent and safe against double-invocation. 3) In sdca_dev_register_functions(), roll back all previously registered functions when a later one fails, so the function array is never left in a partially-populated state. Fixes: 4496d1c65bad ("ASoC: SDCA: add function devices") Signed-off-by: Kean Ren <rh_king@163.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260611023757.1553960-1-rh_king@163.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
38480ffb69 |
ASoC: loongson: Fix invalid position error in ls_pcm_pointer
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit 6ad3914e06a48a02e362d0df2b1073c7c567c93d Author: Li Jun <lijun01@kylinos.cn> Date: Thu Jun 11 09:00:45 2026 +0800 ASoC: loongson: Fix invalid position error in ls_pcm_pointer The "invalid position" error occurred when the DMA position descriptor returned an invalid address value (e.g., pos = -1048838144). This happened because the `bytes_to_frames()` function returns a signed value, but when `addr < runtime->dma_addr`, the subtraction produces a negative result that gets interpreted as a large unsigned integer in comparisons. when the addr is abnormal, for example,the DMA controller is abnormal in hardware,x=0 should not be a point(x == runtime->buffer_size),but a range, which includes the addr address being less than runtime ->dma1-adr, and the addr exceeding the DMA address range.the value of pos should not better a negative，return 0, maybe better. [ 32.834431][ 2] soc-audio soc-audio: invalid position: , pos = -1048838144 [ 32.845019][ 2] soc-audio soc-audio: invalid position: , pos = -1048838144 [ 32.855588][ 2] soc-audio soc-audio: invalid position: , pos = -1048838144 [ 32.866145][ 2] soc-audio soc-audio: invalid position: , pos = -1048838144 [ 32.995394][ 2] soc-audio soc-audio: invalid position: , pos = -1048838144 [ 33.006025][ 2] soc-audio soc-audio: invalid position: , pos = -1048838144 [ 33.016748][ 2] soc-audio soc-audio: invalid position: , pos = -1048838144 Signed-off-by: Li Jun <lijun01@kylinos.cn> [Remove XRUN reporting I'd mistakenly avised adding on prior review -- broonie] Link: https://patch.msgid.link/20260611010045.3668574-1-lijun01@kylinos.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
3ed884c9cd |
ASoC: cs35l56: Cleanup if component_probe fails
JIRA: https://issues.redhat.com/browse/RHEL-183295
commit a0df7522dfb098d56b42560247082d6f5a8581dd
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Wed Jun 10 10:34:32 2026 +0100
ASoC: cs35l56: Cleanup if component_probe fails
If cs35l56_component_probe() fails, call cs35l56_component_remove() to
clean up.
All the cleanup in cs35l56_component_remove() is the same cleanup that
would need to be done (at least partially) if cs35l56_component_probe()
fails. So calling cs35l56_component_remove() avoids convoluted cleanup
gotos and duplicated code in cs35l56_component_probe().
The only action in cs35l56_component_remove() that is nominally
dependent on having completed the component_probe() action is the call
to wm_adsp2_component_remove(). Though it is currently safe to call that
even if wm_adsp2_component_probe() was not called. However,
wm_adsp2_component_probe() has been trivially updated to check itself
whether it needs to cleanup.
Fixes:
|
||
|
Jaroslav Kysela
|
3a52790a79 |
ASoC: cs35l56: Prevent double-free of debugfs
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit 344a12ca7ba6e10f9779476780afe9d977d47322 Author: Richard Fitzgerald <rf@opensource.cirrus.com> Date: Wed Jun 10 10:34:31 2026 +0100 ASoC: cs35l56: Prevent double-free of debugfs Invalidate the debugfs pointer after debugfs_remove_recursive() in cs35l56_remove_cal_debugfs(). This prevents a double-free situation when a future commit adds proper failure cleanup in cs35l56_component_probe(). As described by Sashiko (including the future cs35l56_component_probe() cleanup commit): During a normal component unbind, cs35l56_component_remove() calls cs35l56_remove_cal_debugfs() which removes the directory but leaves a dangling pointer. If the component is later bound again, but _cs35l56_component_probe() fails early (for example, if the init_completion times out), this new error path will call cs35l56_component_remove(). This causes cs35l56_remove_cal_debugfs() to be called again with the dangling cs35l56_base->debugfs pointer from the previous lifecycle, resulting in a use-after-free in debugfs_remove_recursive(). Fixes: f7097161e94c ("ASoC: cs35l56: Add common code for factory calibration") Reported-by: sashiko <sashiko@sashiko.dev> Link: https://sashiko.dev/#/patchset/20260609120738.284770-1-rf%40opensource.cirrus.com Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260610093432.557375-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
917608c75a |
ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()
JIRA: https://issues.redhat.com/browse/RHEL-183295
commit 85f7bf03632bfcdd6cedfb3945b7e387d9487d73
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Wed Jun 10 10:34:30 2026 +0100
ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()
Call wm_adsp2_remove() in cs35l56_remove() and the error path of
cs35l56_common_probe().
Depends on commit 7d3fb78b5503 ("ASoC: wm_adsp: Fix NULL dereference
when removing firmware controls").
The call to wm_halo_init() during driver probe should be paired with
a call to wm_adsp2_remove() but this was missing. The consequence
would be a memory leak of the control lists in the cs_dsp driver.
Fixes:
|
||
|
Jaroslav Kysela
|
00ed1f5444 |
ALSA: timer: Disable work at freeing timer object
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit 764e7ed16d2d6a5948a9e8032b2ef7f77678a8ae Author: Takashi Iwai <tiwai@suse.de> Date: Tue Jun 9 13:50:55 2026 +0200 ALSA: timer: Disable work at freeing timer object There might be a pending work at freeing a timer object, hence clean it up properly. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260609115100.806869-4-tiwai@suse.de Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
157ad20dd3 |
ALSA: timer: Manage timer object with kref
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit ccd0db6671d2cae986b2daa1c538b6d541a9d62c Author: Takashi Iwai <tiwai@suse.de> Date: Tue Jun 9 13:50:53 2026 +0200 ALSA: timer: Manage timer object with kref So far we've tried to address UAFs in ALSA timer code by applying the locks at various places, but the fundamental problem is that the timer object may be released while the belonging timer instance objects are still present and accessing to it. This patch is a more proper fix to address that issue, namely, by refcounting and keeping the timer object. The basic implementation is to use kref for the refcount of the timer object, and take/release the reference at assigning/releasing the instance, as well as at referring from ioctls or ALSA sequencer code. The reference from ioctl or ALSA sequencer is abstracted with snd_timeri_timer auto-cleanup. Note that this change assumes that the code already took the fix commit da3039e91d1f ("ALSA: timer: Forcibly close timer instances at closing"); otherwise the refcount may be unbalanced when the timer is freed while slave instances are still present. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260609115100.806869-2-tiwai@suse.de Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
e8da4c509a |
Revert "ALSA: timer: Fix UAF at snd_timer_user_params()"
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit dde75ff0f651182b671da700441406b8f9de3984 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Jun 9 13:50:54 2026 +0200 Revert "ALSA: timer: Fix UAF at snd_timer_user_params()" This reverts commit 053a401b592be424fea9d57c789f66cd5d8cec11. With the change of the timer object lifecycle with kref, this temporary workaround is no longer needed. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260609115100.806869-3-tiwai@suse.de Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
dbeff6801a |
ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK PM1403CDA
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit 0e152e4126fa14e697d8514cdd1567b18c679f08 Author: Zhang Heng <zhangheng@kylinos.cn> Date: Thu Jun 4 20:58:15 2026 +0800 ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK PM1403CDA Add a DMI quirk for the ASUS EXPERTBOOK PM1403CDA fixing the issue where the internal microphone was not detected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221608 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260604125815.42297-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
08e111c338 |
ASoC: SOF: amd: set ipc flags to zero
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit 25b17c06040fae60518b4ff9c46f2bb12285d538 Author: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Date: Tue Jun 9 21:38:45 2026 +0530 ASoC: SOF: amd: set ipc flags to zero As per design, set IPC conf structure flags to zero during acp init sequence. Link: https://github.com/thesofproject/linux/pull/5642 Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Tested-by: Umang Jain <uajain@igalia.com> Link: https://patch.msgid.link/20260609160938.3717513-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
fc557ef363 |
ASoC: SOF: amd: fix for ipc flags check
JIRA: https://issues.redhat.com/browse/RHEL-183295
commit 6042c91df60e825625bc7d5c5c3b5a87b91d5805
Author: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Date: Tue Jun 9 21:38:44 2026 +0530
ASoC: SOF: amd: fix for ipc flags check
Firmware will set dsp_ack to 1 when firmware sends response for the IPC
command issued by host. Similarly dsp_msg flag will be updated to 1.
During ACP D0 entry, the value read from the sof_dsp_ack_write scratch
flag can be uninitialized. A non-zero garbage value is treated as a
pending DSP IPC ack before SOF_FW_BOOT_COMPLETE, causing a spurious
"IPC reply before FW_BOOT_COMPLETE" log.
Fix the condition checks for ipc flags.
Fixes:
|
||
|
Jaroslav Kysela
|
e2fa9f26ab |
ASoC: wm_adsp: Fix NULL dereference when removing firmware controls
JIRA: https://issues.redhat.com/browse/RHEL-183295
commit 7d3fb78b550301e43fdc60312aed733069694426
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date: Thu Jun 4 11:12:44 2026 +0100
ASoC: wm_adsp: Fix NULL dereference when removing firmware controls
In wm_adsp_control_remove() check that the priv pointer is not NULL
before attempting to cleanup what it points to.
When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that
wm_adsp can create its own private control data. There are two cases
where private data is not created:
1. The control is a SYSTEM control, so an ALSA control is not created.
2. The codec driver has registered a control_add() callback that
hides the control, so wm_adsp_control_add() is not called.
When cs_dsp_remove destroys its control list it calls
wm_adsp_control_remove() for each control. But wm_adsp_control_remove()
was attempting to cleanup the private data pointed to by cs_ctl->priv
without checking the pointer for NULL.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes:
|
||
|
Jaroslav Kysela
|
4d75466713 |
ALSA: timer: Fix UAF at snd_timer_user_params()
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit 053a401b592be424fea9d57c789f66cd5d8cec11 Author: Takashi Iwai <tiwai@suse.de> Date: Sat Jun 6 18:11:41 2026 +0200 ALSA: timer: Fix UAF at snd_timer_user_params() At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng <kylebot@openai.com> Tested-by: Kyle Zeng <kylebot@openai.com> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
63cef3c1d8 |
ALSA: timer: Forcibly close timer instances at closing
JIRA: https://issues.redhat.com/browse/RHEL-183295
commit da3039e91d1f835874ed6e9a33ea19ee80c2cb92
Author: Takashi Iwai <tiwai@suse.de>
Date: Sat Jun 6 18:11:40 2026 +0200
ALSA: timer: Forcibly close timer instances at closing
When snd_timer object is freed via snd_timer_free() and still pending
snd_timer_instance objects are assigned to the timer object, it tries
to unlink all instances and just set NULL to each ti->timer, then
releases the resources immediately. The problem is, however, when
there are slave timer instances that are associated with a master
instance linked to this timer: namely, those slave instances still
point to the freed timer object although the master instance is
unlinked, which may lead to user-after-free. The bug can be easily
triggered particularly when a new userspace-driven timers
(CONFIG_SND_UTIMER) is involved, since it can create and delete the
timer object via a simple file open/close, while the other
applications may keep accessing to that timer.
This patch is an attempt to paper over the problem above: now instead
of just unlinking, call snd_timer_close[_locked]() forcibly for each
pending timer instance, so that all assigned slave timer instances are
properly detached, too. Since snd_timer_close() might be called later
by the driver that created that instance, the check of
SNDRV_TIMER_IFLG_DEAD is added at the beginning, too.
Reported-by: Kyle Zeng <kylebot@openai.com>
Tested-by: Kyle Zeng <kylebot@openai.com>
Fixes:
|
||
|
Jaroslav Kysela
|
f629752dcd |
ALSA: pcm: Fix unlocked runtime state reads in xfer ioctls
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit 98fe3988a2efe89a1a1ded213a0561e6543e94e2 Author: Cássio Gabriel <cassiogabrielcontato@gmail.com> Date: Fri Jun 5 12:48:27 2026 -0300 ALSA: pcm: Fix unlocked runtime state reads in xfer ioctls The recent runtime state locking cleanup converted several PCM ioctl state checks to snd_pcm_get_state(), including snd_pcm_pre_prepare(), snd_pcm_drain() and snd_pcm_kernel_ioctl(). The native and compat xfer ioctl paths still sample runtime->state directly before dispatching to the PCM transfer helpers, and snd_pcm_common_ioctl() still samples the DISCONNECTED state directly in its common precheck. Use snd_pcm_get_state() for those ioctl-side prechecks as well. This keeps the externally visible ioctl entry checks consistent with the stream-locked state access used by the recent PCM state-read cleanup. Fixes: 032322b44c02 ("ALSA: pcm: oss: use proper stream lock for runtime->state access") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260605-alsa-pcm-xfer-state-helper-v1-1-eba97cecf820@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
dfe4535da8 |
ALSA: seq: dummy: fix UMP event stack overread
JIRA: https://issues.redhat.com/browse/RHEL-183295
commit 2b5ff4db5d7aa5b981d966df02e687f79ad7b311
Author: Kyle Zeng <kylebot@openai.com>
Date: Fri Jun 5 01:02:04 2026 -0700
ALSA: seq: dummy: fix UMP event stack overread
The dummy sequencer port forwards events by copying an incoming
struct snd_seq_event into a stack temporary, rewriting source and
destination, and dispatching the temporary to subscribers. That legacy
event storage is smaller than struct snd_seq_ump_event.
When a UMP event reaches the dummy client, the copy leaves the UMP flag
set but only provides legacy-sized stack storage. The subscriber
delivery path then uses snd_seq_event_packet_size() and copies a
UMP-sized packet from that stack object, reading past the end of the
temporary.
Use the existing union __snd_seq_event storage and copy the packet size
reported for the incoming event before rewriting the common routing
fields. This preserves the full UMP packet for UMP events while keeping
legacy event handling unchanged.
Fixes:
|
||
|
Jaroslav Kysela
|
4f8ff19459 |
ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit d76b56b06b2734c6e0ff519599126919fa4f154b Author: Lianqin Hu <hulianqin@vivo.com> Date: Thu Jun 4 12:40:28 2026 +0000 ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio Setting up the interface when suspended/resumeing fail on this card. Adding a reset and delay quirk will eliminate this problem. usb 1-1: new full-speed USB device number 2 using xhci-hcd usb 1-1: New USB device found, idVendor=3c20, idProduct=3d21 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: AB13X USB Audio usb 1-1: Manufacturer: Generic usb 1-1: SerialNumber: 20210726905926 Signed-off-by: Lianqin Hu <hulianqin@vivo.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/TYUPR06MB62174610061C213260E1A992D2102@TYUPR06MB6217.apcprd06.prod.outlook.com Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
d695e594b7 |
ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit 88fe2e3658726cb21ff2dcf9770bf672f9b9d31b Author: Ji'an Zhou <eilaimemedsnaimel@gmail.com> Date: Thu Jun 4 14:25:59 2026 +0000 ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases. Fixes: 9b1dbd69ba6f ("ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain") Signed-off-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com> Link: https://patch.msgid.link/20260604142559.3840881-1-eilaimemedsnaimel@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |
||
|
Jaroslav Kysela
|
bd3a6fad59 |
ASoC: amd: acp70: add standalone RT721 SoundWire machine
JIRA: https://issues.redhat.com/browse/RHEL-183295 commit d2dcd85f9e09fe3566d4cdcd357856a42ac73f93 Author: Aleksander Pshenitsyn <brains.fatman@gmail.com> Date: Sun May 31 13:11:59 2026 +0300 ASoC: amd: acp70: add standalone RT721 SoundWire machine The ASUS Vivobook 18 M1807GA (AMD ACP7.x, PCI 1022:15e2, subsystem 1043:3531) exposes a single Realtek RT721 SDCA codec on SoundWire link 1. The BIOS reports the ACP audio config flag as 0 (SoundWire mode), so snd_pci_ps claims the device, brings up the SoundWire managers and enumerates the RT721 peripheral (sdw:0:1:025d:0721:01); the rt721-sdca codec driver binds successfully. No sound card is created, however: acp63_sdw_machine_select() walks snd_soc_acpi_amd_acp70_sdw_machines[] and finds no entry whose declared SoundWire peripherals are all present on the bus. The only existing RT721 entry, acp70_rt721_l1u0_tas2783x2_l1u8b, additionally requires two TAS2783 amplifiers and deliberately exposes the RT721 as jack + DMIC only. This M1807GA variant has no external amplifiers - the RT721's internal AIF2 amplifier path drives the speakers - so that entry never matches and no machine device is registered. Add a standalone RT721 machine entry for link 1 exposing all three RT721 endpoints (jack/AIF1, speaker amplifier/AIF2, DMIC/AIF3), mirroring the standalone RT722 configuration. Place it after the TAS2783 combo entry so platforms that do have the external amplifiers continue to match the more specific entry first. ACPI _ADR of the codec: 0x000130025D072101 (link_id=1 version=3 mfg_id=0x025d Realtek part_id=0x0721 class=0x01). Verified on the hardware: with the entry present the amd_sdw machine binds, an "amd-soundwire" card is registered exposing the rt721-sdca AIF1 (SimpleJack) and AIF2 (SmartAmp) PCM devices, and audio plays out of the built-in speakers. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221282 Signed-off-by: Aleksander Pshenitsyn <brains.fatman@gmail.com> Link: https://patch.msgid.link/20260531101159.14241-1-brains.fatman@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jaroslav Kysela <jkysela@redhat.com> |