2019-07-22 13:58:36

by Wenwen Wang

[permalink] [raw]
Subject: [PATCH] ASoC: dapm: fix a memory leak bug

From: Wenwen Wang <[email protected]>

In snd_soc_dapm_new_control_unlocked(), a kernel buffer is allocated in
dapm_cnew_widget() to hold the new dapm widget. Then, different actions are
taken according to the id of the widget, i.e., 'w->id'. If any failure
occurs during this process, snd_soc_dapm_new_control_unlocked() should be
terminated by going to the 'request_failed' label. However, the allocated
kernel buffer is not freed on this code path, leading to a memory leak bug.

To fix the above issue, free the buffer before returning from
snd_soc_dapm_new_control_unlocked() through the 'request_failed' label.

Signed-off-by: Wenwen Wang <[email protected]>
---
sound/soc/soc-dapm.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index f013b24..23b9b25 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -3706,6 +3706,8 @@ snd_soc_dapm_new_control_unlocked(struct snd_soc_dapm_context *dapm,
dev_err(dapm->dev, "ASoC: Failed to request %s: %d\n",
w->name, ret);

+ kfree_const(w->sname);
+ kfree(w);
return ERR_PTR(ret);
}

--
2.7.4


2019-07-23 18:04:04

by Charles Keepax

[permalink] [raw]
Subject: Re: [alsa-devel] [PATCH] ASoC: dapm: fix a memory leak bug

On Mon, Jul 22, 2019 at 08:57:44AM -0500, Wenwen Wang wrote:
> From: Wenwen Wang <[email protected]>
>
> In snd_soc_dapm_new_control_unlocked(), a kernel buffer is allocated in
> dapm_cnew_widget() to hold the new dapm widget. Then, different actions are
> taken according to the id of the widget, i.e., 'w->id'. If any failure
> occurs during this process, snd_soc_dapm_new_control_unlocked() should be
> terminated by going to the 'request_failed' label. However, the allocated
> kernel buffer is not freed on this code path, leading to a memory leak bug.
>
> To fix the above issue, free the buffer before returning from
> snd_soc_dapm_new_control_unlocked() through the 'request_failed' label.
>
> Signed-off-by: Wenwen Wang <[email protected]>
> ---

Reviewed-by: Charles Keepax <[email protected]>

Thanks,
Charles