linux.git/sound, branch v7.3-rc2 Linux kernel source tree 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: caiaq: Fix potential double-free at error path 2026-09-03T16:08:24+00:00 Takashi Iwai tiwai@suse.de 2026-09-03T10:38:51+00:00 3b26ceef88c110f4d188387cffa0df78657be904 The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared. Link: https://sashiko.dev/#/patchset/20260903084747.535367-1-eadavis%40sina.com Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly") Link: https://patch.msgid.link/20260903103855.1807838-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> 
The fix for caiaq driver's resource management to handle the errors
tries to release the resources in a common destructor call, but as a
sashiko review for another patch suggested, some of the audio
resources such as URBs have been already freed, and this may lead to a
double-free.

For addressing the double-free, call the common destructor function
from each place, and assure that the resource pointers get cleared.

Link: https://sashiko.dev/#/patchset/20260903084747.535367-1-eadavis%40sina.com
Fixes: 28abd224db4a ("ALSA: caiaq: Handle probe errors properly")
Link: https://patch.msgid.link/20260903103855.1807838-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda/realtek: Fix cold-boot headset misdetection on Acer Aspire A515-57G 2026-09-02T18:08:59+00:00 Oleksandr Kovalov oleksandr.kovalov.work@gmail.com 2026-09-02T17:13:05+00:00 8ba27b90095a4c7fcc878dd013969cd6b100cea7 On the Acer Aspire A515-57G (PCI SSID 1025:1616), if headphones are already inserted into the combo jack before the codec powers up (a cold boot with the plug already seated), the impedance-based headset-type sensing races and misclassifies the jack. This drives the wrong output configuration and is audible as missing center-panned content (e.g. vocals) while panned content plays normally. A genuine physical unplug/replug after boot reliably fixes this by forcing a fresh sense transient, which is a strong hint about the underlying cause: the sensing hardware appears to need a settled, freshly-triggered read rather than the one-shot classification done during the normal HDA_FIXUP_ACT_INIT pass. Add a machine-specific fixup that, on cold boot only (not S3/S4 resume, which already gets its own re-check), waits briefly after the normal init-time decision and then forces a fresh headset-mode classification by resetting the cached mode and re-invoking the existing alc_fixup_headset_mode() path -- mirroring what a manual replug already does. The wait+recheck is skipped whenever the first pass already determined nothing is plugged in, to avoid adding boot latency on the common case. Chain into the existing ALC256_FIXUP_ACER_SFG16_MICMUTE_LED fixup so this quirk-table entry keeps providing mic-mute LED support alongside the cold-boot headset fix. Tested on kernel 7.1.9 by building the affected module standalone and confirming cold boot with headphones pre-inserted plays correctly from the very first sample, across multiple boots (including a full restart, and headphones inserted mid-POST rather than before power-on), with no crashes or warnings and no behavioral difference from a real post-replug recovery. Signed-off-by: Oleksandr Kovalov <oleksandr.kovalov.work@gmail.com> Link: https://patch.msgid.link/20260902171305.3955-1-oleksandr.kovalov.work@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
On the Acer Aspire A515-57G (PCI SSID 1025:1616), if headphones are
already inserted into the combo jack before the codec powers up (a cold
boot with the plug already seated), the impedance-based headset-type
sensing races and misclassifies the jack. This drives the wrong output
configuration and is audible as missing center-panned content (e.g.
vocals) while panned content plays normally.

A genuine physical unplug/replug after boot reliably fixes this by
forcing a fresh sense transient, which is a strong hint about the
underlying cause: the sensing hardware appears to need a settled,
freshly-triggered read rather than the one-shot classification done
during the normal HDA_FIXUP_ACT_INIT pass.

Add a machine-specific fixup that, on cold boot only (not S3/S4 resume,
which already gets its own re-check), waits briefly after the normal
init-time decision and then forces a fresh headset-mode classification
by resetting the cached mode and re-invoking the existing
alc_fixup_headset_mode() path -- mirroring what a manual replug already
does. The wait+recheck is skipped whenever the first pass already
determined nothing is plugged in, to avoid adding boot latency on the
common case.

Chain into the existing ALC256_FIXUP_ACER_SFG16_MICMUTE_LED fixup so
this quirk-table entry keeps providing mic-mute LED support alongside
the cold-boot headset fix.

Tested on kernel 7.1.9 by building the affected module standalone and
confirming cold boot with headphones pre-inserted plays correctly from
the very first sample, across multiple boots (including a full restart,
and headphones inserted mid-POST rather than before power-on), with no
crashes or warnings and no behavioral difference from a real
post-replug recovery.

Signed-off-by: Oleksandr Kovalov <oleksandr.kovalov.work@gmail.com>
Link: https://patch.msgid.link/20260902171305.3955-1-oleksandr.kovalov.work@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: hda/cs420x: Add CS4208 fixup for MacBookAir 7,2 2026-09-02T06:41:02+00:00 Jonne Vuorela jonne.vuorela@proton.me 2026-09-01T18:28:27+00:00 82cfab6a52621febf36752bd5ed5184f82c96e07 The MacBookAir 7,2 HDA controller has PCI subsystem 8086:7270 rather than Apple 0x106b, so no fixup is selected and all pins default to 0x400000f0. The pin wiring matches MBA6, so add the subsystem ID to both lookup tables pointing to CS4208_MBA6. Tested on MacBookAir 7,2. [ sorted table entries in SSID order -- tiwai ] Signed-off-by: Jonne Vuorela <jonne.vuorela@proton.me> Link: https://patch.msgid.link/Qcui5livawCaJbO1jfx_jebS64rR0f9KATkqn8May0pPyLw8U5DqPQBigmSzRxJp-GeMPqs-jAK6PCnagk3bspzmH__YPte-eyvPtFtuolo=@proton.me Signed-off-by: Takashi Iwai <tiwai@suse.de> 
The MacBookAir 7,2 HDA controller has PCI subsystem 8086:7270
rather than Apple 0x106b, so no fixup is selected and all pins
default to 0x400000f0. The pin wiring matches MBA6, so add the
subsystem ID to both lookup tables pointing to CS4208_MBA6.

Tested on MacBookAir 7,2.

[ sorted table entries in SSID order -- tiwai ]

Signed-off-by: Jonne Vuorela <jonne.vuorela@proton.me>
Link: https://patch.msgid.link/Qcui5livawCaJbO1jfx_jebS64rR0f9KATkqn8May0pPyLw8U5DqPQBigmSzRxJp-GeMPqs-jAK6PCnagk3bspzmH__YPte-eyvPtFtuolo=@proton.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: dummy: Report a change when one capture switch channel moves 2026-09-01T16:25:53+00:00 HyeongJun An sammiee5311@gmail.com 2026-09-01T15:39:21+00:00 83162eeaf78c71ff6f6fa31dc95e3b6e90ee593f The snd_dummy_capsrc_put() builds its change flag with &&, so it reports a change only when both channels move at once. Writing a single channel stores the new value and returns 0, the control core then sends no SNDRV_CTL_EVENT_MASK_VALUE, and a second reader keeps showing the old setting until it polls again. The volume put a few lines above compares the same pair of channels with ||. The mixer selftest already reports this. With snd-dummy loaded it fails event_missing on all five capture switches: # CD Capture Switch.1 orig 0 read 1, is_volatile 0 not ok 13 event_missing.Dummy.9 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Link: https://patch.msgid.link/20260901153921.3971-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
The snd_dummy_capsrc_put() builds its change flag with &&, so it reports
a change only when both channels move at once.  Writing a single channel
stores the new value and returns 0, the control core then sends no
SNDRV_CTL_EVENT_MASK_VALUE, and a second reader keeps showing the old
setting until it polls again.

The volume put a few lines above compares the same pair of channels with
||.

The mixer selftest already reports this.  With snd-dummy loaded it fails
event_missing on all five capture switches:

  # CD Capture Switch.1 orig 0 read 1, is_volatile 0
  not ok 13 event_missing.Dummy.9

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260901153921.3971-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: usb-audio: Add mixer map quirk for Audient iD24 2026-09-01T10:39:37+00:00 Peter Drabik drabik.p@gmail.com 2026-08-31T19:58:55+00:00 c53f5bfc370046e098fe04dc045e9e3cf19df609 The Audient iD24 (2708:000d) exposes feature unit 12 as a 4-channel "Speaker Playback Volume" control (cmask 0xf, -127..0 dB). The device does not actually apply this volume to all of its output channels: the left main output ignores it and stays at 0 dB, while the right main output honors it. When userspace (PulseAudio / PipeWire in a stereo profile) adopts this control as the master playback volume, any setting below maximum produces a stereo imbalance on the main outputs. This was verified against the device's internal meters: with the control set to 107/127 (-20 dB) on all four channels and a digitally identical L/R sine played back, both DAW return meters read the same level while the right main output metered exactly 20 dB below the left. Restoring the control to 127 (0 dB) restored the balance. Rename the control to "Monitor Mix Playback" so that it is not picked up as the stream's master volume control, in line with similar quirks for other devices. The control remains accessible for manual use. Signed-off-by: Peter Drabik <drabik.p@gmail.com> Link: https://patch.msgid.link/20260831195855.1836617-1-drabik.p@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
The Audient iD24 (2708:000d) exposes feature unit 12 as a 4-channel
"Speaker Playback Volume" control (cmask 0xf, -127..0 dB).  The device
does not actually apply this volume to all of its output channels: the
left main output ignores it and stays at 0 dB, while the right main
output honors it.

When userspace (PulseAudio / PipeWire in a stereo profile) adopts this
control as the master playback volume, any setting below maximum
produces a stereo imbalance on the main outputs.

This was verified against the device's internal meters: with the
control set to 107/127 (-20 dB) on all four channels and a digitally
identical L/R sine played back, both DAW return meters read the same
level while the right main output metered exactly 20 dB below the
left.  Restoring the control to 127 (0 dB) restored the balance.

Rename the control to "Monitor Mix Playback" so that it is not picked
up as the stream's master volume control, in line with similar quirks
for other devices.  The control remains accessible for manual use.

Signed-off-by: Peter Drabik <drabik.p@gmail.com>
Link: https://patch.msgid.link/20260831195855.1836617-1-drabik.p@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda: restore MFG widget enumeration after core split 2026-09-01T10:37:33+00:00 Xu Rao raoxu@uniontech.com 2026-09-01T03:40:24+00:00 32d7226e6105c257ef7b3d0ec819f11a81f53b6d Before commit 7639a06c23c7 ("ALSA: hda - Move a part of hda_codec stuff into hdac_device"), widget enumeration selected the function group with codec->afg ? codec->afg : codec->mfg and read subordinate nodes from that group. The core split moved this logic into snd_hdac_refresh_widgets(), but hard-coded codec->afg there. For an MFG-only codec, codec->afg is zero, so the Root Node is queried and codec->start_nid/num_nodes are populated from the function-group range instead of the MFG's subordinate nodes. Restore the pre-split AFG-or-MFG selection. Fixes: 7639a06c23c7 ("ALSA: hda - Move a part of hda_codec stuff into hdac_device") Signed-off-by: Xu Rao <raoxu@uniontech.com> Link: https://patch.msgid.link/44809B8FF80DCCA2+20260901034024.2407783-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
Before commit 7639a06c23c7 ("ALSA: hda - Move a part of hda_codec stuff
into hdac_device"), widget enumeration selected the function group with

	codec->afg ? codec->afg : codec->mfg

and read subordinate nodes from that group.

The core split moved this logic into snd_hdac_refresh_widgets(), but
hard-coded codec->afg there. For an MFG-only codec, codec->afg is zero,
so the Root Node is queried and codec->start_nid/num_nodes are populated
from the function-group range instead of the MFG's subordinate nodes.

Restore the pre-split AFG-or-MFG selection.

Fixes: 7639a06c23c7 ("ALSA: hda - Move a part of hda_codec stuff into hdac_device")
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Link: https://patch.msgid.link/44809B8FF80DCCA2+20260901034024.2407783-1-raoxu@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() 2026-09-01T10:36:53+00:00 HyeongJun An sammiee5311@gmail.com 2026-09-01T09:04:09+00:00 e4637ce34607f1733a34a57294966d26b263e626 The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here. Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Link: https://patch.msgid.link/20260901090409.1478573-1-sammiee5311@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
The snd_usbmidi_us122l_output() picks a count of 2 on anything slower
than high speed and never relates it to ep->max_transfer.  The URB
buffer holds exactly max_transfer bytes, so a device declaring a one
byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the
memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX.

Only 0x800e and 0x800f are pinned to nine bytes.  The US-122MKII at
0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the
USB core only clamps downward.

The akai and novation output ops in this file were given the same guard
recently.  Do the same here.

Fixes: 030a07e44129 ("ALSA: Add USB US122L driver")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260901090409.1478573-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>