ASoC: SOF: topology: Fix bytes control size checks
diff mbox series

Message ID 20191106145816.9367-1-pierre-louis.bossart@linux.intel.com
State Accepted
Commit 2acdcabb8a4089476208a822050dd47a6557290d
Headers show
Series
  • ASoC: SOF: topology: Fix bytes control size checks
Related show

Commit Message

Pierre-Louis Bossart Nov. 6, 2019, 2:58 p.m. UTC
From: Dragos Tarcatu <dragos_tarcatu@mentor.com>

When using the example SOF amp widget topology, KASAN dumps this
when the AMP bytes kcontrol gets loaded:

[ 9.579548] BUG: KASAN: slab-out-of-bounds in
sof_control_load+0x8cc/0xac0 [snd_sof]
[ 9.588194] Write of size 40 at addr ffff8882314559dc by task
systemd-udevd/2411

Fix that by rejecting the topology if the bytes data size > max_size

Fixes: 311ce4fe7637d ("ASoC: SOF: Add support for loading topologies")
Reviewed-by: Jaska Uimonen <jaska.uimonen@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
---
 sound/soc/sof/topology.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

Comments

Mark Brown Nov. 6, 2019, 4:29 p.m. UTC | #1
On Wed, Nov 06, 2019 at 04:21:46PM +0000, Mark Brown wrote:
> The patch
> 
>    ASoC: SOF: topology: Fix bytes control size checks
> 
> has been applied to the asoc tree at
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4

It's not immediately obvious if something similar is needed for -next,
the relevant code has been redone since v5.4 was branched off.  If
something is needed someone will have to send something.
Pierre-Louis Bossart Nov. 6, 2019, 4:49 p.m. UTC | #2
On 11/6/19 10:29 AM, Mark Brown wrote:
> On Wed, Nov 06, 2019 at 04:21:46PM +0000, Mark Brown wrote:
>> The patch
>>
>>     ASoC: SOF: topology: Fix bytes control size checks
>>
>> has been applied to the asoc tree at
>>
>>     https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
> 
> It's not immediately obvious if something similar is needed for -next,
> the relevant code has been redone since v5.4 was branched off.  If
> something is needed someone will have to send something.

I checked that the patch applies even before Jaska's October rework, 
where the same bug was present. so in theory picking this fix for 
5.2..5.4 would work as usual.
Mark Brown Nov. 6, 2019, 4:54 p.m. UTC | #3
On Wed, Nov 06, 2019 at 10:49:20AM -0600, Pierre-Louis Bossart wrote:
> On 11/6/19 10:29 AM, Mark Brown wrote:
> > On Wed, Nov 06, 2019 at 04:21:46PM +0000, Mark Brown wrote:

> > It's not immediately obvious if something similar is needed for -next,
> > the relevant code has been redone since v5.4 was branched off.  If
> > something is needed someone will have to send something.

> I checked that the patch applies even before Jaska's October rework, where
> the same bug was present. so in theory picking this fix for 5.2..5.4 would
> work as usual.

What I'm saying is that I did that and if the fix is still needed after
the rework someone will need to send a version that applies after the
rework.
Pierre-Louis Bossart Nov. 6, 2019, 6:15 p.m. UTC | #4
On 11/6/19 10:54 AM, Mark Brown wrote:
> On Wed, Nov 06, 2019 at 10:49:20AM -0600, Pierre-Louis Bossart wrote:
>> On 11/6/19 10:29 AM, Mark Brown wrote:
>>> On Wed, Nov 06, 2019 at 04:21:46PM +0000, Mark Brown wrote:
> 
>>> It's not immediately obvious if something similar is needed for -next,
>>> the relevant code has been redone since v5.4 was branched off.  If
>>> something is needed someone will have to send something.
> 
>> I checked that the patch applies even before Jaska's October rework, where
>> the same bug was present. so in theory picking this fix for 5.2..5.4 would
>> work as usual.
> 
> What I'm saying is that I did that and if the fix is still needed after
> the rework someone will need to send a version that applies after the
> rework.

Sorry, the same patch will apply before and after the rework, so you can 
apply it to for-next as well. You don't need a new version.

Patch
diff mbox series

diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index 17fe6a1d5f3e..6096731e89ce 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -1048,15 +1048,16 @@  static int sof_control_load_bytes(struct snd_soc_component *scomp,
 	struct soc_bytes_ext *sbe = (struct soc_bytes_ext *)kc->private_value;
 	int max_size = sbe->max;
 
-	if (le32_to_cpu(control->priv.size) > max_size) {
+	/* init the get/put bytes data */
+	scontrol->size = sizeof(struct sof_ipc_ctrl_data) +
+		le32_to_cpu(control->priv.size);
+
+	if (scontrol->size > max_size) {
 		dev_err(sdev->dev, "err: bytes data size %d exceeds max %d.\n",
-			control->priv.size, max_size);
+			scontrol->size, max_size);
 		return -EINVAL;
 	}
 
-	/* init the get/put bytes data */
-	scontrol->size = sizeof(struct sof_ipc_ctrl_data) +
-		le32_to_cpu(control->priv.size);
 	scontrol->control_data = kzalloc(max_size, GFP_KERNEL);
 	cdata = scontrol->control_data;
 	if (!scontrol->control_data)