[PATCH] ASoC: dapm: Fix empty list check in dapm_new_mux()

[PATCH] ASoC: dapm: Fix empty list check in dapm_new_mux()

[Lars-Peter Clausen]

list_first_entry() will always return a valid pointer, even if the list is
empty. So the check whether path is NULL will always be false. So we end up
calling dapm_create_or_share_mixmux_kcontrol() with a path struct that points
right in the middle of the widget struct and by trying to modify the path the
widgets memory will become corrupted. Fix this by using list_emtpy() to check if
the widget doesn't have any paths.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>

---
This is the real fix for the rt5640 crash.
---
 sound/soc/soc-dapm.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 5f64c16..196cea7 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -747,13 +747,14 @@ static int dapm_new_mux(struct snd_soc_dapm_widget *w)
 		return -EINVAL;
 	}
 
-	path = list_first_entry(&w->sources, struct snd_soc_dapm_path,
-				list_sink);
-	if (!path) {
+	if (list_empty(&w->sources)) {
 		dev_err(dapm->dev, "ASoC: mux %s has no paths\n", w->name);
 		return -EINVAL;
 	}
 
+	path = list_first_entry(&w->sources, struct snd_soc_dapm_path,
+				list_sink);
+
 	ret = dapm_create_or_share_mixmux_kcontrol(w, 0, path);
 	if (ret < 0)
 		return ret;
-- 
1.8.0

Re: [PATCH] ASoC: dapm: Fix empty list check in dapm_new_mux()

[Stephen Warren]

On 08/01/2013 10:30 AM, Lars-Peter Clausen wrote:
> list_first_entry() will always return a valid pointer, even if the list is
> empty. So the check whether path is NULL will always be false. So we end up
> calling dapm_create_or_share_mixmux_kcontrol() with a path struct that points
> right in the middle of the widget struct and by trying to modify the path the
> widgets memory will become corrupted. Fix this by using list_emtpy() to check if
> the widget doesn't have any paths.
> 
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> 
> ---
> This is the real fix for the rt5640 crash.

Tested-by: Stephen Warren <swarren@nvidia.com>

Re: [PATCH] ASoC: dapm: Fix empty list check in dapm_new_mux()

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 597 bytes --]

On Thu, Aug 01, 2013 at 06:30:38PM +0200, Lars-Peter Clausen wrote:
> list_first_entry() will always return a valid pointer, even if the list is
> empty. So the check whether path is NULL will always be false. So we end up
> calling dapm_create_or_share_mixmux_kcontrol() with a path struct that points
> right in the middle of the widget struct and by trying to modify the path the
> widgets memory will become corrupted. Fix this by using list_emtpy() to check if
> the widget doesn't have any paths.

Applied, thanks - looking at this I'm surprised we've not been running
into problems before.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH] ASoC: dapm: Fix empty list check in dapm_new_mux()

[Stephen Warren]

On 08/01/2013 12:44 PM, Mark Brown wrote:
> On Thu, Aug 01, 2013 at 06:30:38PM +0200, Lars-Peter Clausen
> wrote:
>> list_first_entry() will always return a valid pointer, even if
>> the list is empty. So the check whether path is NULL will always
>> be false. So we end up calling
>> dapm_create_or_share_mixmux_kcontrol() with a path struct that
>> points right in the middle of the widget struct and by trying to
>> modify the path the widgets memory will become corrupted. Fix
>> this by using list_emtpy() to check if the widget doesn't have
>> any paths.
> 
> Applied, thanks - looking at this I'm surprised we've not been
> running into problems before.

I don't see this in the ASoC git tree, in either for-next, fix/dapm,
or topic/dapm.

Re: [PATCH] ASoC: dapm: Fix empty list check in dapm_new_mux()

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 213 bytes --]

On Fri, Aug 02, 2013 at 09:43:50AM -0600, Stephen Warren wrote:

> I don't see this in the ASoC git tree, in either for-next, fix/dapm,
> or topic/dapm.

I see it...  it missed -next due to being pushed out late.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]