- Sound-open-firmware - mailman.alsa-project.org

[PATCH 0/2] Add SoundWire machines for ACP7.0/ACP7.1 sof stack
by Vijendar Mukunda 25 Jun '25

25 Jun '25

Add SoundWire machines as alternate machines for ACP7.0 & ACP7.1 platforms with the below machine configuration. Link 0: RT722 codec with three endpoints: Headset, Speaker, and DMIC. Vijendar Mukunda (2): ASoC: amd: acp: add soundwire machine for ACP7.0 and ACP7.1 sof stack ASoC: SOF: amd: add alternate machines for ACP7.0 and ACP7.1 platforms sound/soc/amd/acp/Kconfig | 1 + sound/soc/amd/acp/amd-acp70-acpi-match.c | 12 ++++++++++++ sound/soc/amd/mach-config.h | 1 + sound/soc/sof/amd/pci-acp70.c | 1 + 4 files changed, 15 insertions(+) -- 2.45.2

2 3

Re: [PATCH] ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.
by Mark Brown 24 Jun '25

24 Jun '25

On Mon, 16 Jun 2025 08:55:48 +0900, Tamura Dai wrote: > sof_pdata->tplg_filename can have address allocated by kstrdup() > and can be overwritten. Memory leak was detected with kmemleak: > > unreferenced object 0xffff88812391ff60 (size 16): > comm "kworker/4:1", pid 161, jiffies 4294802931 > hex dump (first 16 bytes): > 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. > backtrace (crc 4bf1675c): > __kmalloc_node_track_caller_noprof+0x49c/0x6b0 > kstrdup+0x46/0xc0 > hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic] > sof_init_environment+0x16f/0xb50 [snd_sof] > sof_probe_continue+0x45/0x7c0 [snd_sof] > sof_probe_work+0x1e/0x40 [snd_sof] > process_one_work+0x894/0x14b0 > worker_thread+0x5e5/0xfb0 > kthread+0x39d/0x760 > ret_from_fork+0x31/0x70 > ret_from_fork_asm+0x1a/0x30 > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak. commit: 6c038b58a2dc5a008c7e7a1297f5aaa4deaaaa7e All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

Re: [PATCH RESEND v2] ASoC: SOF: Intel: hda: Fix UAF when reloading module
by Péter Ujfalusi 04 Jun '25

04 Jun '25

On 06/05/2025 18:12, Tavian Barnes wrote: > hda_generic_machine_select() appends -idisp to the tplg filename by > allocating a new string with devm_kasprintf(), then stores the string > right back into the global variable snd_soc_acpi_intel_hda_machines. > When the module is unloaded, this memory is freed, resulting in a global > variable pointing to freed memory. Reloading the modules then triggers > a use-after-free: > > BUG: KFENCE: use-after-free read in string+0x48/0xe0 > > Use-after-free read at 0x00000000967e0109 (in kfence-#99): > string+0x48/0xe0 > vsnprintf+0x329/0x6e0 > devm_kvasprintf+0x54/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 > > allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): > devm_kmalloc+0x52/0x120 > devm_kvasprintf+0x66/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): > release_nodes+0x43/0xb0 > devres_release_all+0x90/0xf0 > device_unbind_cleanup+0xe/0x70 > device_release_driver_internal+0x1c1/0x200 > driver_detach+0x48/0x90 > bus_remove_driver+0x6d/0xf0 > pci_unregister_driver+0x42/0xb0 > __do_sys_delete_module+0x1d1/0x310 > do_syscall_64+0x82/0x190 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > Fix it by saving the filename in pdata->tplg_filename instead, just like > every other code path that appends to the tplg filename. > > Fixes: 5458411d7594 ("ASoC: SOF: Intel: hda: refactoring topology name fixup for HDA mach") > Signed-off-by: Tavian Barnes <tavianator(a)tavianator.com> > --- > v2: Fix typo > > sound/soc/sof/intel/hda.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c > index b34e5fdf10f1..1767977e7cff 100644 > --- a/sound/soc/sof/intel/hda.c > +++ b/sound/soc/sof/intel/hda.c > @@ -1069,7 +1069,7 @@ static void hda_generic_machine_select(struct snd_sof_dev *sdev, > if (!tplg_filename) > return; > > - hda_mach->sof_tplg_filename = tplg_filename; > + pdata->tplg_filename = tplg_filename; Did you sent this as a mistake? The v5 patch looks to be the correct one, this is not. > } > > if (codec_num == 2 || -- Péter

2 2

[PATCH v5] ASoC: SOF: Intel: hda: Fix UAF when reloading module
by Tavian Barnes 15 May '25

15 May '25

hda_generic_machine_select() appends -idisp to the tplg filename by allocating a new string with devm_kasprintf(), then stores the string right back into the global variable snd_soc_acpi_intel_hda_machines. When the module is unloaded, this memory is freed, resulting in a global variable pointing to freed memory. Reloading the module then triggers a use-after-free: BUG: KFENCE: use-after-free read in string+0x48/0xe0 Use-after-free read at 0x00000000967e0109 (in kfence-#99): string+0x48/0xe0 vsnprintf+0x329/0x6e0 devm_kvasprintf+0x54/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): devm_kmalloc+0x52/0x120 devm_kvasprintf+0x66/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): release_nodes+0x43/0xb0 devres_release_all+0x90/0xf0 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x42/0xb0 __do_sys_delete_module+0x1d1/0x310 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it by copying the match array with devm_kmemdup_array() before we modify it. Fixes: 5458411d7594 ("ASoC: SOF: Intel: hda: refactoring topology name fixup for HDA mach") Suggested-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Acked-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Signed-off-by: Tavian Barnes <tavianator(a)tavianator.com> --- v5: Formatting fix. v4: Copy the whole array, including the sentinel. v3: Copy the whole machine struct instead so we can safely modify it (instead of storing the name in pdata->tplg_filename, breaking other fixups). The problem with v2 was pointed out by Bard Liao, with the alternative fix suggested by Péter Ujfalusi. v2: Typo fix. sound/soc/sof/intel/hda.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index b34e5fdf10f1..6a3932d90b43 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -1049,7 +1049,21 @@ static void hda_generic_machine_select(struct snd_sof_dev *sdev, if (!*mach && codec_num <= 2) { bool tplg_fixup = false; - hda_mach = snd_soc_acpi_intel_hda_machines; + /* + * make a local copy of the match array since we might + * be modifying it + */ + hda_mach = devm_kmemdup_array(sdev->dev, + snd_soc_acpi_intel_hda_machines, + 2, /* we have one entry + sentinel in the array */ + sizeof(snd_soc_acpi_intel_hda_machines[0]), + GFP_KERNEL); + if (!hda_mach) { + dev_err(bus->dev, + "%s: failed to duplicate the HDA match table\n", + __func__); + return; + } dev_info(bus->dev, "using HDA machine driver %s now\n", hda_mach->drv_name); -- 2.49.0

2 1

Re: [PATCH v4] ASoC: SOF: Intel: hda: Fix UAF when reloading module
by Péter Ujfalusi 08 May '25

08 May '25

On 08/05/2025 18:21, Tavian Barnes wrote: > hda_generic_machine_select() appends -idisp to the tplg filename by > allocating a new string with devm_kasprintf(), then stores the string > right back into the global variable snd_soc_acpi_intel_hda_machines. > When the module is unloaded, this memory is freed, resulting in a global > variable pointing to freed memory. Reloading the module then triggers > a use-after-free: > > BUG: KFENCE: use-after-free read in string+0x48/0xe0 > > Use-after-free read at 0x00000000967e0109 (in kfence-#99): > string+0x48/0xe0 > vsnprintf+0x329/0x6e0 > devm_kvasprintf+0x54/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 > > allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): > devm_kmalloc+0x52/0x120 > devm_kvasprintf+0x66/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): > release_nodes+0x43/0xb0 > devres_release_all+0x90/0xf0 > device_unbind_cleanup+0xe/0x70 > device_release_driver_internal+0x1c1/0x200 > driver_detach+0x48/0x90 > bus_remove_driver+0x6d/0xf0 > pci_unregister_driver+0x42/0xb0 > __do_sys_delete_module+0x1d1/0x310 > do_syscall_64+0x82/0x190 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > Fix it by copying the match array with devm_kmemdup_array() before we > modify it. > > Fixes: 5458411d7594 ("ASoC: SOF: Intel: hda: refactoring topology name fixup for HDA mach") > Suggested-by: Péter Ujfalusi" <peter.ujfalusi(a)linux.intel.com> > Signed-off-by: Tavian Barnes <tavianator(a)tavianator.com> > --- > v4: Copy the whole array, including the sentinel. > > v3: Copy the whole machine struct instead so we can safely modify it > (instead of storing the name in pdata->tplg_filename, breaking other > fixups). The problem with v2 was pointed out by Bard Liao, with the > alternative fix suggested by Péter Ujfalusi. > > v2: Typo fix. > > sound/soc/sof/intel/hda.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c > index b34e5fdf10f1..13ecb9473eb6 100644 > --- a/sound/soc/sof/intel/hda.c > +++ b/sound/soc/sof/intel/hda.c > @@ -1049,7 +1049,21 @@ static void hda_generic_machine_select(struct snd_sof_dev *sdev, > if (!*mach && codec_num <= 2) { > bool tplg_fixup = false; > > - hda_mach = snd_soc_acpi_intel_hda_machines; > + /* > + * make a local copy of the match array since we might > + * be modifying it > + */ > + hda_mach = devm_kmemdup_array(sdev->dev, > + snd_soc_acpi_intel_hda_machines, > + 2 /* we have one entry + sentinel in the array */, I would prefer the comment after the comma. and I just noticed that my suggestion had it wrong as well, sorry. With that you can add my: Acked-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> > + sizeof(snd_soc_acpi_intel_hda_machines[0]), > + GFP_KERNEL); > + if (!hda_mach) { > + dev_err(bus->dev, > + "%s: failed to duplicate the HDA match table\n", > + __func__); > + return; > + } > > dev_info(bus->dev, "using HDA machine driver %s now\n", > hda_mach->drv_name); -- Péter

1 0

Re: [PATCH v3] ASoC: SOF: Intel: hda: Fix UAF when reloading module
by Péter Ujfalusi 08 May '25

08 May '25

On 07/05/2025 20:06, Tavian Barnes wrote: >>> - hda_mach = snd_soc_acpi_intel_hda_machines; >>> + /* make a copy so we can modify it below */ >>> + hda_mach = devm_kmemdup(sdev->dev, >>> + snd_soc_acpi_intel_hda_machines, >>> + sizeof(*hda_mach), >>> + GFP_KERNEL); >> >> We need to copy 2x the size as the snd_soc_acpi_intel_hda_machines[] has >> two entries, the second is the sentinel (all 0). > > Do we? I recognize that snd_soc_acpi_intel_hda_machines is an array, > but I don't see anywhere that hda_mach or *mach are used as an array, > at least in hda.c. > > I'm no expert though, if we need the sentinel I can send a v4. Thanks > for the review! Yes, we need to preserve the sentinel. When dealing with the snd_soc_acpi_mach all code looks for the sentinel at the end to break the loops. The size of the arrays are unknown outside where they are defined. -- Péter

1 0

Re: [PATCH v3] ASoC: SOF: Intel: hda: Fix UAF when reloading module
by Péter Ujfalusi 07 May '25

07 May '25

Hi, On 07/05/2025 18:10, Tavian Barnes wrote: > hda_generic_machine_select() appends -idisp to the tplg filename by > allocating a new string with devm_kasprintf(), then stores the string > right back into the global variable snd_soc_acpi_intel_hda_machines. > When the module is unloaded, this memory is freed, resulting in a global > variable pointing to freed memory. Reloading the module then triggers > a use-after-free: > > BUG: KFENCE: use-after-free read in string+0x48/0xe0 > > Use-after-free read at 0x00000000967e0109 (in kfence-#99): > string+0x48/0xe0 > vsnprintf+0x329/0x6e0 > devm_kvasprintf+0x54/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 > > allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): > devm_kmalloc+0x52/0x120 > devm_kvasprintf+0x66/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): > release_nodes+0x43/0xb0 > devres_release_all+0x90/0xf0 > device_unbind_cleanup+0xe/0x70 > device_release_driver_internal+0x1c1/0x200 > driver_detach+0x48/0x90 > bus_remove_driver+0x6d/0xf0 > pci_unregister_driver+0x42/0xb0 > __do_sys_delete_module+0x1d1/0x310 > do_syscall_64+0x82/0x190 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > Fix it by copying the machine with devm_kmemdup() before we modify it. > > Fixes: 5458411d7594 ("ASoC: SOF: Intel: hda: refactoring topology name fixup for HDA mach") > Suggested-by: Péter Ujfalusi" <peter.ujfalusi(a)linux.intel.com> > Signed-off-by: Tavian Barnes <tavianator(a)tavianator.com> > --- > v3: Copy the whole machine struct instead so we can safely modify it > (instead of storing the name in pdata->tplg_filename, breaking other > fixups). The problem with v2 was pointed out by Bard Liao, with the > alternative fix suggested by Péter Ujfalusi. > > sound/soc/sof/intel/hda.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c > index b34e5fdf10f1..cbf96b342005 100644 > --- a/sound/soc/sof/intel/hda.c > +++ b/sound/soc/sof/intel/hda.c > @@ -1049,7 +1049,13 @@ static void hda_generic_machine_select(struct snd_sof_dev *sdev, > if (!*mach && codec_num <= 2) { > bool tplg_fixup = false; > > - hda_mach = snd_soc_acpi_intel_hda_machines; > + /* make a copy so we can modify it below */ > + hda_mach = devm_kmemdup(sdev->dev, > + snd_soc_acpi_intel_hda_machines, > + sizeof(*hda_mach), > + GFP_KERNEL); We need to copy 2x the size as the snd_soc_acpi_intel_hda_machines[] has two entries, the second is the sentinel (all 0). > + if (!hda_mach) > + return; > > dev_info(bus->dev, "using HDA machine driver %s now\n", > hda_mach->drv_name); -- Péter

1 0

Re: [PATCH RESEND v2] ASoC: SOF: Intel: hda: Fix UAF when reloading module
by Péter Ujfalusi 07 May '25

07 May '25

On 06/05/2025 18:12, Tavian Barnes wrote: > hda_generic_machine_select() appends -idisp to the tplg filename by > allocating a new string with devm_kasprintf(), then stores the string > right back into the global variable snd_soc_acpi_intel_hda_machines. > When the module is unloaded, this memory is freed, resulting in a global > variable pointing to freed memory. Reloading the modules then triggers > a use-after-free: > > BUG: KFENCE: use-after-free read in string+0x48/0xe0 > > Use-after-free read at 0x00000000967e0109 (in kfence-#99): > string+0x48/0xe0 > vsnprintf+0x329/0x6e0 > devm_kvasprintf+0x54/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 > > allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): > devm_kmalloc+0x52/0x120 > devm_kvasprintf+0x66/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): > release_nodes+0x43/0xb0 > devres_release_all+0x90/0xf0 > device_unbind_cleanup+0xe/0x70 > device_release_driver_internal+0x1c1/0x200 > driver_detach+0x48/0x90 > bus_remove_driver+0x6d/0xf0 > pci_unregister_driver+0x42/0xb0 > __do_sys_delete_module+0x1d1/0x310 > do_syscall_64+0x82/0x190 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > Fix it by saving the filename in pdata->tplg_filename instead, just like > every other code path that appends to the tplg filename. > > Fixes: 5458411d7594 ("ASoC: SOF: Intel: hda: refactoring topology name fixup for HDA mach") > Signed-off-by: Tavian Barnes <tavianator(a)tavianator.com> > --- > v2: Fix typo > > sound/soc/sof/intel/hda.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c > index b34e5fdf10f1..1767977e7cff 100644 > --- a/sound/soc/sof/intel/hda.c > +++ b/sound/soc/sof/intel/hda.c > @@ -1069,7 +1069,7 @@ static void hda_generic_machine_select(struct snd_sof_dev *sdev, > if (!tplg_filename) > return; > > - hda_mach->sof_tplg_filename = tplg_filename; > + pdata->tplg_filename = tplg_filename; > } > > if (codec_num == 2 || I think the correct way would be to make a local copy of the snd_soc_acpi_intel_hda_machines array as we might be modifying it: /* * make a local copy of the match array since we might * be modifying it */ hda_mach = devm_kmemdup_array(sdev->dev, snd_soc_acpi_intel_hda_machines, 2 /* we have one entry + sentinel in the array */, sizeof(snd_soc_acpi_intel_hda_machines[0]), GFP_KERNEL); if (!hda_mach) { dev_err(bus->dev, "%s: Failed to duplicate the HDA match table\n", __func__); return; } or if the "2" is not satisfactory (we _know_ that the array size is 2 for this and will not change): include/sound/soc-acpi-intel-match.h +extern size_t snd_soc_acpi_num_intel_hda_machines; sound/soc/intel/common/soc-acpi-intel-hda-match.c +size_t snd_soc_acpi_num_intel_hda_machines = ARRAY_SIZE(snd_soc_acpi_intel_hda_machines); +EXPORT_SYMBOL_GPL(snd_soc_acpi_num_intel_hda_machines); and: /* * make a local copy of the match array since we might * be modifying it */ hda_mach = devm_kmemdup_array(sdev->dev, snd_soc_acpi_intel_hda_machines, snd_soc_acpi_num_intel_hda_machines, sizeof(snd_soc_acpi_intel_hda_machines[0]), GFP_KERNEL); if (!hda_mach) { dev_err(bus->dev, "%s: Failed to duplicate the HDA match table\n", __func__); return; } -- Péter

1 0

Re: [PATCH RESEND v2] ASoC: SOF: Intel: hda: Fix UAF when reloading module
by Liao, Bard 07 May '25

07 May '25

On 5/6/2025 11:12 PM, Tavian Barnes wrote: > hda_generic_machine_select() appends -idisp to the tplg filename by > allocating a new string with devm_kasprintf(), then stores the string > right back into the global variable snd_soc_acpi_intel_hda_machines. > When the module is unloaded, this memory is freed, resulting in a global > variable pointing to freed memory. Reloading the modules then triggers > a use-after-free: > > BUG: KFENCE: use-after-free read in string+0x48/0xe0 > > Use-after-free read at 0x00000000967e0109 (in kfence-#99): > string+0x48/0xe0 > vsnprintf+0x329/0x6e0 > devm_kvasprintf+0x54/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 > > allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): > devm_kmalloc+0x52/0x120 > devm_kvasprintf+0x66/0xb0 > devm_kasprintf+0x58/0x80 > hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] > sof_probe_work+0x7f/0x600 [snd_sof] > process_one_work+0x17b/0x330 > worker_thread+0x2ce/0x3f0 > kthread+0xcf/0x100 > ret_from_fork+0x31/0x50 > ret_from_fork_asm+0x1a/0x30 > > freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): > release_nodes+0x43/0xb0 > devres_release_all+0x90/0xf0 > device_unbind_cleanup+0xe/0x70 > device_release_driver_internal+0x1c1/0x200 > driver_detach+0x48/0x90 > bus_remove_driver+0x6d/0xf0 > pci_unregister_driver+0x42/0xb0 > __do_sys_delete_module+0x1d1/0x310 > do_syscall_64+0x82/0x190 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > Fix it by saving the filename in pdata->tplg_filename instead, just like > every other code path that appends to the tplg filename. > > Fixes: 5458411d7594 ("ASoC: SOF: Intel: hda: refactoring topology name fixup for HDA mach") > Signed-off-by: Tavian Barnes <tavianator(a)tavianator.com> > --- > v2: Fix typo > > sound/soc/sof/intel/hda.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c > index b34e5fdf10f1..1767977e7cff 100644 > --- a/sound/soc/sof/intel/hda.c > +++ b/sound/soc/sof/intel/hda.c > @@ -1069,7 +1069,7 @@ static void hda_generic_machine_select(struct snd_sof_dev *sdev, > if (!tplg_filename) > return; > > - hda_mach->sof_tplg_filename = tplg_filename; > + pdata->tplg_filename = tplg_filename; It will break the existing tplg name fixup mechanism. Please see below in hda_machine_select() if (!sof_pdata->tplg_filename) { /* remove file extension if it exists */ tplg_filename = remove_file_ext(mach->sof_tplg_filename); if (!tplg_filename) return NULL; sof_pdata->tplg_filename = tplg_filename; tplg_fixup = true; } With the change, sof_pdata->tplg_filename will be set and we won't do tplg fixup for other components. > } > > if (codec_num == 2 ||

1 0

Re: [PATCH v3 0/4] AsoC: Phase out hybrid PCI devres
by Mark Brown 07 May '25

07 May '25

On Fri, 25 Apr 2025 10:17:39 +0200, Philipp Stanner wrote: > Changes in v3: > - Remove two forgotten calls to pci_release_regions(). (Amadeusz) > - Adjust commit titles to common format. (Amadeusz, Cezary) > - Apply RB by Czeray (not everywhere, two patches changed, see point > 1 above) > > Changes in v2: > - sof: simplify return. (Andy) > - intel/atom: simplify return. (Andy) > - Send a separate series for AsoC. (Andy) > - intel/atom: Add another patch that switches EINVAL to ENOMEM. (Andy) > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/4] ASoC: sof: Use pure devres PCI commit: 45054bb10fd8a545a1feeaab16af1a87ab7fcce3 [2/4] ASoC: intel: avs: Use pure devres PCI commit: 58fa9c629e29ae921d055c2b7a1e372ae991fb79 [3/4] AsoC: intel: atom: Use pure devres PCI commit: 938cabc603dc9b040fbfbf7c37b2b48dff8946d4 [4/4] AsoC: intel: atom: Return -ENOMEM if pcim_iomap() fails commit: 14a3fd030c033453d436233f4c422b4903786ed3 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0