linux-toradex.git/sound/core, branch master Linux kernel for Apalis and Colibri modules Merge tag 'asoc-fix-v7.3-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus 2026-09-17T06:15:32+00:00 Takashi Iwai tiwai@suse.de 2026-09-17T06:15:32+00:00 546b928da0427b0d6c663cbb992bd7bfa9ac7971 ASoC: Fixes for v7.3 A relatively large pile of fixes here, a lot of driver specific stuff that's broadly unremarkable plus a few core fixes from Richard that fix issues where SoundWire systems with multiple CODECs on the same link would configure the CODECs to use the same bus slots leading to broken audio. 
ASoC: Fixes for v7.3

A relatively large pile of fixes here, a lot of driver specific stuff
that's broadly unremarkable plus a few core fixes from Richard that fix
issues where SoundWire systems with multiple CODECs on the same link
would configure the CODECs to use the same bus slots leading to broken
audio.
ALSA: pcm: set timer->private_data before registering the PCM timer 2026-09-13T16:38:03+00:00 Nguyen Ngoc Thang ngocthang2710.1999@gmail.com 2026-09-13T13:44:46+00:00 1e713f9bb2ac583521f06b0eb4e22440b1e3d078 snd_pcm_timer_init() calls snd_device_register() to link the new struct snd_timer into the global timer list while it still carries hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop), and only afterwards sets timer->private_data = substream. Once the timer is on the list under register_mutex, a concurrent reader can already reach it through the same mutex and invoke these callbacks. /proc/asound/timers does this via c_resolution(), and snd_timer_open()+snd_timer_start() reach start()/stop() the same way. All three dereference timer->private_data, which for this brief window is NULL, giving a NULL-pointer dereference: substream = timer->private_data; return substream->runtime ? ... // substream is NULL Move the private_data/private_free assignment before snd_device_register() so the timer is never visible on the list without its private_data set. On the snd_device_register() failure path, private_free() (snd_pcm_timer_free()) can now run, but it only does substream->timer = NULL, which is already NULL at that point since substream->timer is set to the new timer just once, after a successful registration -- so the failure path stays safe. Reported-by: syzbot+19da64013c46df87f971@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=19da64013c46df87f971 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com> Link: https://patch.msgid.link/20260913134446.114724-1-ngocthang2710.1999@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
snd_pcm_timer_init() calls snd_device_register() to link the new
struct snd_timer into the global timer list while it still carries
hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop),
and only afterwards sets timer->private_data = substream.

Once the timer is on the list under register_mutex, a concurrent
reader can already reach it through the same mutex and invoke these
callbacks. /proc/asound/timers does this via c_resolution(), and
snd_timer_open()+snd_timer_start() reach start()/stop() the same way.
All three dereference timer->private_data, which for this brief
window is NULL, giving a NULL-pointer dereference:

  substream = timer->private_data;
  return substream->runtime ? ...   // substream is NULL

Move the private_data/private_free assignment before
snd_device_register() so the timer is never visible on the list
without its private_data set. On the snd_device_register() failure
path, private_free() (snd_pcm_timer_free()) can now run, but it only
does substream->timer = NULL, which is already NULL at that point
since substream->timer is set to the new timer just once, after a
successful registration -- so the failure path stays safe.

Reported-by: syzbot+19da64013c46df87f971@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=19da64013c46df87f971
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Link: https://patch.msgid.link/20260913134446.114724-1-ngocthang2710.1999@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: core: Fix potential UAF after asynchronous card release 2026-09-13T07:07:08+00:00 Takashi Iwai tiwai@suse.de 2026-09-12T16:21:42+00:00 fd95e68df6fe66344161a1329cbe5e5805e7b704 Usually a sound driver releases the resources assigned to the card via snd_card_free(), and it synchronizes with the whole release procedure. However, when the card is released asynchronously via snd_card_free_when_closed() like USB-audio driver, the situation is slightly different; although the snd_card_disconnect() call at the disconnection guarantees that any newer accesses will be gated, the in-flight tasks might be still accessing to the underlying card->dev device even after the disconnection, which would cause a use-after-free in the end, as reported by fuzzers. For addressing the bug above, this patch takes the refcount of card->dev at initialization of the card object, and releases at its destructor. This assures the availability of the card->dev in its whole lifecycle. Reported-by: Farhad Alemi <farhad.alemi@berkeley.edu> Closes: https://lore.kernel.org/CA+0ovChexj4TrZL_2iG_P0WBEbZc5+73GfB3DkciQi=R8pZOnA@mail.gmail.com Closes: https://lore.kernel.org/CA+0ovCgQUQNN=Z1tJTouiCsDaXR5M-3-SQEGk-cpPXQkM5Xh+w@mail.gmail.com Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20260912162150.455144-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> 
Usually a sound driver releases the resources assigned to the card via
snd_card_free(), and it synchronizes with the whole release procedure.
However, when the card is released asynchronously via
snd_card_free_when_closed() like USB-audio driver, the situation is
slightly different; although the snd_card_disconnect() call at the
disconnection guarantees that any newer accesses will be gated, the
in-flight tasks might be still accessing to the underlying card->dev
device even after the disconnection, which would cause a
use-after-free in the end, as reported by fuzzers.

For addressing the bug above, this patch takes the refcount of
card->dev at initialization of the card object, and releases at its
destructor.   This assures the availability of the card->dev in its
whole lifecycle.

Reported-by: Farhad Alemi <farhad.alemi@berkeley.edu>
Closes: https://lore.kernel.org/CA+0ovChexj4TrZL_2iG_P0WBEbZc5+73GfB3DkciQi=R8pZOnA@mail.gmail.com
Closes: https://lore.kernel.org/CA+0ovCgQUQNN=Z1tJTouiCsDaXR5M-3-SQEGk-cpPXQkM5Xh+w@mail.gmail.com
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260912162150.455144-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
treewide: refresh kmalloc_obj() conversions 2026-09-05T04:37:00+00:00 Kees Cook kees+treewide@kernel.org 2026-09-02T22:31:14+00:00 3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook <kees+treewide@kernel.org> 
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci

This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.

Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.

Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
ALSA: rawmidi: Return the error from snd_rawmidi_input_params() 2026-09-02T13:30:14+00:00 HyeongJun An sammiee5311@gmail.com 2026-09-02T12:50:58+00:00 f4a23e17d84fd2a152d9e12369761934e1af0ee8 The snd_rawmidi_input_params() computes err for the three invalid mode combinations and for resize_runtime_buffer(), applies the new framing and clock type only when err is zero, and then returns 0 anyway. A caller that asked for parameters the kernel rejected is told the change succeeded, and the substream keeps its old buffer. The open_mutex conversion turned the early returns into assignments. It handled the output sibling correctly, which still returns err, and left this one behind. Fixes: 94b98194b62e ("ALSA: rawmidi: Take open_mutex around parameter changes") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Link: https://patch.msgid.link/20260902125058.19499-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
The snd_rawmidi_input_params() computes err for the three invalid mode
combinations and for resize_runtime_buffer(), applies the new framing
and clock type only when err is zero, and then returns 0 anyway.  A
caller that asked for parameters the kernel rejected is told the change
succeeded, and the substream keeps its old buffer.

The open_mutex conversion turned the early returns into assignments.
It handled the output sibling correctly, which still returns err, and
left this one behind.

Fixes: 94b98194b62e ("ALSA: rawmidi: Take open_mutex around parameter changes")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260902125058.19499-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: ump: do not touch legacy_rmidi before it exists 2026-09-02T09:10:49+00:00 Qingyu Zhang usupergate@gmail.com 2026-09-02T07:39:18+00:00 adeee7187694719890aaffdc14b7e89cfd736f1d snd_ump_parse_endpoint() sets ump->parsed on every exit, including error, before the caller attaches the legacy rawmidi device. ump_handle_ep_name_msg() then treats parsed as "legacy_rmidi is live" and calls ump_legacy_set_rawmidi_name(), which snprintf()s into ump->legacy_rmidi->name. If a UMP packet arrives in that window (IRQ path from snd_ump_receive), legacy_rmidi is still NULL (KASAN null-ptr-deref in snprintf). Guard the legacy helpers. parsed only means endpoint info was parsed, not that legacy_rmidi exists. Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing") Signed-off-by: Qingyu Zhang <usupergate@gmail.com> Link: https://patch.msgid.link/20260902073918.880245-1-usupergate@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
snd_ump_parse_endpoint() sets ump->parsed on every exit, including
error, before the caller attaches the legacy rawmidi device.
ump_handle_ep_name_msg() then treats parsed as "legacy_rmidi is live"
and calls ump_legacy_set_rawmidi_name(), which snprintf()s into
ump->legacy_rmidi->name. If a UMP packet arrives in that window
(IRQ path from snd_ump_receive), legacy_rmidi is still NULL
(KASAN null-ptr-deref in snprintf).

Guard the legacy helpers. parsed only means endpoint info was
parsed, not that legacy_rmidi exists.

Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing")
Signed-off-by: Qingyu Zhang <usupergate@gmail.com>
Link: https://patch.msgid.link/20260902073918.880245-1-usupergate@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF 2026-08-31T08:10:15+00:00 Yilin Zhang yilinzhang@moonshot.ai 2026-08-31T04:55:06+00:00 9b110a9dcecc59516c77cb3c0caf1f492f75df2d snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request. Reported-by: Kimi Security Team <bug-report@moonshot.ai> Fixes: 92ee3c60ec9f ("ALSA: pcm: Fix races among concurrent hw_params and hw_free calls") Signed-off-by: Yilin Zhang <yilinzhang@moonshot.ai> Link: https://patch.msgid.link/20260831045506.889070-1-yilinzhang@moonshot.ai Signed-off-by: Takashi Iwai <tiwai@suse.de> 
snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation
with an mmap_count check performed under the PCM stream lock, but the
lock is released long before the buffer is actually freed:
snd_pcm_sync_stop(), constraint refinement and do_free_pages() all
happen in between.  snd_pcm_mmap_data(), on the other hand, takes no
lock at all: it validates against the old buffer's state and
dma_bytes, remaps its pages into the VMA, and only then increments
mmap_count.

A concurrent mmap() can therefore slip in between the check and the
free.  remap_pfn_range() installs writable PTEs for the old buffer's
pages without taking page references, and the subsequent
do_free_pages() returns those pages to the page allocator while the
VMA still maps them.  This leaves a stale, writable mapping of freed
pages: a page-level use-after-free that can be leveraged for local
privilege escalation.

Make snd_pcm_mmap_data() participate in the buffer-access scheme
introduced for hw_params/hw_free: acquire runtime->buffer_accessing
before validating and remapping, and release it afterwards.  Buffer
reallocation already fails with -EBUSY while accessors are active,
and the mmap side now fails with -EBUSY while a reallocation is in
progress, so the validate/remap sequence and the check/free sequence
can no longer interleave.

A reproducer that turns this race into a stale writable mapping of
the freed DMA buffer pages is available on request.

Reported-by: Kimi Security Team <bug-report@moonshot.ai>
Fixes: 92ee3c60ec9f ("ALSA: pcm: Fix races among concurrent hw_params and hw_free calls")
Signed-off-by: Yilin Zhang <yilinzhang@moonshot.ai>
Link: https://patch.msgid.link/20260831045506.889070-1-yilinzhang@moonshot.ai
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: pcm: Fix race between non-atomic ops and trigger-start 2026-08-31T08:06:16+00:00 Takashi Iwai tiwai@suse.de 2026-08-28T11:55:39+00:00 acac7b5e07349a9d10d78873afb4b93cd1dc721f We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running. Reported-by: syzbot+225231fce6755d40d078@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a8f0de8.1d9ded08.62e62.00b5.GAE@google.com Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20260828115542.3999-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> 
We protect the races of the concurrent state transitions between
atomic PCM ops, but the checks between the non-atomic ops (hw_params,
hw_free and prepare) and the atomic ops aren't perfect; there is a
check of the conflicting PCM state at the beginning of hw_params & co,
but the atomic PCM ops can be still issued during the non-atomic PCM
operations.  An example such scenario is that a thread A re-issues the
PREPARE or HW_PARAMS for the already prepared stream, while another
thread B triggers the PCM start in the middle of the prepare
operation.  Although this usually doesn't lead to much serious issues,
it can give some inconsistency as reported by syzkaller (such as
ODEBUG warning).

There are various atomic PCM ops, and basically the only problem is
the PCM start as it operates from the PREPARED state.  Other trigger
commands (stop, etc) are for the running or the other special state,
hence they are filtered as pre-condition.

This patch is for preventing the PCM trigger-start during the non-
atomic operations in order to address the problems above.
Fortunately, the hw_params, hw_free and prepare operations call
snd_pcm_buffer_access_lock(), and this can be used for checking the
concurrent operations at the PCM trigger -- which sets the
runtime->buffer_accessing to a negative (if possible), so the PCM
trigger just needs to check the runtime->buffer_accessing value; if
it's negative, it means the concurrent non-atomic PCM ops is running.

Reported-by: syzbot+225231fce6755d40d078@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/6a8f0de8.1d9ded08.62e62.00b5.GAE@google.com
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260828115542.3999-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge tag 'sound-fix-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound 2026-08-28T17:01:02+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-08-28T17:01:02+00:00 c20313e98b04ce543936431b6122dd639d3a8346 Pull sound fixes from Takashi Iwai: "A collection of various small fixes since the last PR. Most changes are device-specific fixes, while there are a few fixes addressing the issues reported recently by fuzzers. Here are highlights: ALSA Core: - Prevent adding invalid kcontrols to the LED layer - Workaround for a false-positive mutex lockdep warning in rawmidi USB-audio: - Relaxed the sticky mixer behavior check that caused regressions - Fix an OOB write in Novation MIDI output - Proper cleanup after system-resume errors - Quirk updates for M-Audio Venom, Audient iD14 MkI, Logitech PRO X Wireless, SMSL USB DAC, and Creative Sound Blaster Play! 3 HD-audio: - Conexant headset plugin fixes - Quirk additions and fixes for HP Laptop 15, Lenovo IdeaPad Slim 3, TongFang XxAF5xxx, Lenovo Legion Pro 7, and Lenovo Yoga Pro 9 ASoC: - DAPM: Fix off-by-one check on the second enum channel - Tegra: Fix and sort register defaults - AMD quirk updates for ASUS FA401EA, HP OmniBook X Flip 16, HVY-WXX9/M1060, Alienware m18 R1, and MSI Thin A15 B7UC - Fixes Qualcomm TDM handling - Fix double put_device() on SoundWire - Codec fixes for rt766, tac5xx2, rt712, tas2783, and max98926 Misc: - Fix card leak on probe error on ice1712 driver - Hardening for legacy aoa, mtpav and pcxhr drivers" * tag 'sound-fix-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (53 commits) ALSA: control: Don't add invalid kcontrols to LED layer ASoC: amd: acp-config: change quirks to cover all ASUS FA401EA variants ALSA: hda/conexant: Always enable the headset-mic pin on plugin ASoC: dapm: Fix off-by-one check on the second enum channel ASoC: amd: acp-config: force SoundWire probe on HP OmniBook X Flip 16 ASoC: amd: acp3x-es83xx: Add HVY-WXX9/M1060 DMI quirk ASoC: amd: acp-config: Add HVY-WXX9/M1060 DMI quirk ASoC: soc-generic-dmaengine: Fix DMA channel request warning ALSA: rawmidi: Another workaround for false-positive mutex lockdep warning ASoC: amd: yc: Add DMI entry for Alienware m18 R1 AMD ASoC: amd: yc: Add DMI entry for MSI Thin A15 B7UC ALSA: hda/realtek: Fix speaker mute LED for HP Laptop 15-fd0039nt ALSA: usb-audio: Complete cleanup after system-resume errors ALSA: hda/realtek: Add quirk for Lenovo IdeaPad Slim 3 15ABR8 ALSA: aoa: i2sbus: Check IRQ before requesting it ALSA: usb-audio: Skip mixer creation on M-Audio Venom ALSA: usb-audio: Skip reading sample rate on M-Audio Venom ASoC: rt766: add RT766/RT767 VA1 device IDs ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() ... 
Pull sound fixes from Takashi Iwai:
 "A collection of various small fixes since the last PR. Most changes
  are device-specific fixes, while there are a few fixes addressing the
  issues reported recently by fuzzers.

  Here are highlights:

  ALSA Core:
   - Prevent adding invalid kcontrols to the LED layer
   - Workaround for a false-positive mutex lockdep warning in rawmidi

  USB-audio:
   - Relaxed the sticky mixer behavior check that caused regressions
   - Fix an OOB write in Novation MIDI output
   - Proper cleanup after system-resume errors
   - Quirk updates for M-Audio Venom, Audient iD14 MkI, Logitech PRO X
     Wireless, SMSL USB DAC, and Creative Sound Blaster Play! 3

  HD-audio:
   - Conexant headset plugin fixes
   - Quirk additions and fixes for HP Laptop 15, Lenovo IdeaPad Slim 3,
     TongFang XxAF5xxx, Lenovo Legion Pro 7, and Lenovo Yoga Pro 9

  ASoC:
   - DAPM: Fix off-by-one check on the second enum channel
   - Tegra: Fix and sort register defaults
   - AMD quirk updates for ASUS FA401EA, HP OmniBook X Flip 16,
     HVY-WXX9/M1060, Alienware m18 R1, and MSI Thin A15 B7UC
   - Fixes Qualcomm TDM handling
   - Fix double put_device() on SoundWire
   - Codec fixes for rt766, tac5xx2, rt712, tas2783, and max98926

  Misc:
   - Fix card leak on probe error on ice1712 driver
   - Hardening for legacy aoa, mtpav and pcxhr drivers"

* tag 'sound-fix-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (53 commits)
  ALSA: control: Don't add invalid kcontrols to LED layer
  ASoC: amd: acp-config: change quirks to cover all ASUS FA401EA variants
  ALSA: hda/conexant: Always enable the headset-mic pin on plugin
  ASoC: dapm: Fix off-by-one check on the second enum channel
  ASoC: amd: acp-config: force SoundWire probe on HP OmniBook X Flip 16
  ASoC: amd: acp3x-es83xx: Add HVY-WXX9/M1060 DMI quirk
  ASoC: amd: acp-config: Add HVY-WXX9/M1060 DMI quirk
  ASoC: soc-generic-dmaengine: Fix DMA channel request warning
  ALSA: rawmidi: Another workaround for false-positive mutex lockdep warning
  ASoC: amd: yc: Add DMI entry for Alienware m18 R1 AMD
  ASoC: amd: yc: Add DMI entry for MSI Thin A15 B7UC
  ALSA: hda/realtek: Fix speaker mute LED for HP Laptop 15-fd0039nt
  ALSA: usb-audio: Complete cleanup after system-resume errors
  ALSA: hda/realtek: Add quirk for Lenovo IdeaPad Slim 3 15ABR8
  ALSA: aoa: i2sbus: Check IRQ before requesting it
  ALSA: usb-audio: Skip mixer creation on M-Audio Venom
  ALSA: usb-audio: Skip reading sample rate on M-Audio Venom
  ASoC: rt766: add RT766/RT767 VA1 device IDs
  ALSA: hda/realtek: Add quirk for TongFang XxAF5xxx
  ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output()
  ...
ALSA: control: Don't add invalid kcontrols to LED layer 2026-08-27T14:15:08+00:00 Takashi Iwai tiwai@suse.de 2026-08-27T11:39:03+00:00 74e3b979ce8b78a690f8b94ccf2e2c965f7f5c11 The kcontrol LED state layer tries to track the all associated kcontrol elements with naive assumptions that they are readable. But one can create a write-only element that has no get callback (even a user element can do it), and this may lead to a NULL dereference at the call chain of snd_ctl_led_notify(), as found by syzkaller. For avoiding the Oops, add a sanity check of the kcontrol's info and get callbacks, and just skip the invalid kcontrols before assigning the kctl to the LED layer. Reported-by: syzbot+b7fe2760ea6f1ee44b4d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/6a9007b3.1d9ded08.62e62.00cd.GAE@google.com Fixes: 22d8de62f11b ("ALSA: control - add generic LED trigger module as the new control layer") Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260827113951.893291-1-tiwai@suse.de 
The kcontrol LED state layer tries to track the all associated
kcontrol elements with naive assumptions that they are readable.
But one can create a write-only element that has no get callback (even
a user element can do it), and this may lead to a NULL dereference at
the call chain of snd_ctl_led_notify(), as found by syzkaller.

For avoiding the Oops, add a sanity check of the kcontrol's info and
get callbacks, and just skip the invalid kcontrols before assigning
the kctl to the LED layer.

Reported-by: syzbot+b7fe2760ea6f1ee44b4d@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/6a9007b3.1d9ded08.62e62.00cd.GAE@google.com
Fixes: 22d8de62f11b ("ALSA: control - add generic LED trigger module as the new control layer")
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260827113951.893291-1-tiwai@suse.de