[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOReqxhDpmexe_aLHb2-ESjSE2uij2SrPxRCZD3YxZm0JjtwrA@mail.gmail.com>
Date: Mon, 18 Apr 2022 18:59:17 -0700
From: Curtis Malainey <cujomalainey@...gle.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
ALSA development <alsa-devel@...a-project.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Takashi Iwai <tiwai@...e.com>,
Tomasz Figa <tfiga@...omium.org>,
Mark Brown <broonie@...nel.org>,
Ricardo Ribalda <ribalda@...omium.org>,
Jaroslav Kysela <perex@...ex.cz>,
Sound Open Firmware <sound-open-firmware@...a-project.org>
Subject: Re: [Sound-open-firmware] out-of-bounds access in sound/soc/sof/topology.c
> Now control data allocations looks as follows
>
> scontrol->size = struct_size(scontrol->control_data, chanv,
> le32_to_cpu(mc->num_channels));
> scontrol->control_data = kzalloc(scontrol->size, GFP_KERNEL);
>
> Which is sizeof(sof_ipc_ctrl_data) + mc->num_channels * sizeof(sof_ipc_ctrl_value_chan)
>
> For some reason it uses sizeof(sof_ipc_ctrl_value_chan), which is not
> the largest member of the union.
>
For the record, this could be hitting as far back as 5.4 as I have
been trying to debug an invalid IPC write in JSL.
Powered by blists - more mailing lists