CVE-2025-38486

In the Linux kernel, the following vulnerability has been resolved:

soundwire: Revert "soundwire: qcom: Add set_channel_map api support"

This reverts commit 7796c97df6b1b2206681a07f3c80f6023a6593d5.

This patch broke Dragonboard 845c (sdm845). I see:

Unexpected kernel BRK exception at EL1
Internal error: BRK handler: 00000000f20003e8 [#1]  SMP
pc : qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom]
lr : snd_soc_dai_set_channel_map+0x34/0x78
Call trace:
 qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom] (P)
 sdm845_dai_init+0x18c/0x2e0 [snd_soc_sdm845]
 snd_soc_link_init+0x28/0x6c
 snd_soc_bind_card+0x5f4/0xb0c
 snd_soc_register_card+0x148/0x1a4
 devm_snd_soc_register_card+0x50/0xb0
 sdm845_snd_platform_probe+0x124/0x148 [snd_soc_sdm845]
 platform_probe+0x6c/0xd0
 really_probe+0xc0/0x2a4
 __driver_probe_device+0x7c/0x130
 driver_probe_device+0x40/0x118
 __device_attach_driver+0xc4/0x108
 bus_for_each_drv+0x8c/0xf0
 __device_attach+0xa4/0x198
 device_initial_probe+0x18/0x28
 bus_probe_device+0xb8/0xbc
 deferred_probe_work_func+0xac/0xfc
 process_one_work+0x244/0x658
 worker_thread+0x1b4/0x360
 kthread+0x148/0x228
 ret_from_fork+0x10/0x20
Kernel panic - not syncing: BRK handler: Fatal exception

Dan has also reported following issues with the original patch https://lore.kernel.org/all/[email protected]/

Bug #1: The zeroeth element of ctrl->pconfig[] is supposed to be unused. We start counting at 1. However this code sets ctrl->pconfig[0].ch_mask = 128.

Bug #2: There are SLIM_MAX_TX_PORTS (16) elements in tx_ch[] array but only QCOM_SDW_MAX_PORTS + 1 (15) in the ctrl->pconfig[] array so it corrupts memory like Yongqin Liu pointed out.

Bug 3: Like Jie Gan pointed out, it erases all the tx information with the rx information.

This vulnerability does not affect supported Red Hat Enterprise Linux releases because the susceptible code is not present in shipped kernels. The flaw involves out-of-bounds array indexing and memory corruption during audio channel configuration within the Qualcomm SoundWire driver on specific ARM hardware platforms. Because the problematic driver implementation was introduced only in newer upstream development releases, Red Hat systems do not experience operational or security impact from this flaw.