[PATCH] ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.

Tamura Dai posted 1 patch 3 months, 3 weeks ago
sound/soc/sof/intel/hda.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
[PATCH] ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.
Posted by Tamura Dai 3 months, 3 weeks ago
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

Signed-off-by: Tamura Dai <kirinode0@gmail.com>
---
 sound/soc/sof/intel/hda.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c
index bdfe388da198..3b47191ea7a5 100644
--- a/sound/soc/sof/intel/hda.c
+++ b/sound/soc/sof/intel/hda.c
@@ -1257,11 +1257,11 @@ static int check_tplg_quirk_mask(struct snd_soc_acpi_mach *mach)
 	return 0;
 }
 
-static char *remove_file_ext(const char *tplg_filename)
+static char *remove_file_ext(struct device *dev, const char *tplg_filename)
 {
 	char *filename, *tmp;
 
-	filename = kstrdup(tplg_filename, GFP_KERNEL);
+	filename = devm_kstrdup(dev, tplg_filename, GFP_KERNEL);
 	if (!filename)
 		return NULL;
 
@@ -1345,7 +1345,7 @@ struct snd_soc_acpi_mach *hda_machine_select(struct snd_sof_dev *sdev)
 		 */
 		if (!sof_pdata->tplg_filename) {
 			/* remove file extension if it exists */
-			tplg_filename = remove_file_ext(mach->sof_tplg_filename);
+			tplg_filename = remove_file_ext(sdev->dev, mach->sof_tplg_filename);
 			if (!tplg_filename)
 				return NULL;
 
-- 
2.39.5
Re: [PATCH] ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.
Posted by Mark Brown 3 months, 2 weeks ago
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