[PATCH] ASoC: Intel: avs: Use struct_size for struct avs_modcfg_ext size
The struct avs_modcfg_ext structure has a flexible array member for the pin_fmts array, and the size should be calculated using struct_size to prevent the potential for overflow with the allocation.
Signed-off-by: Jacob Keller jacob.e.keller@intel.com Reviewed-by: Cezary Rojewski cezary.rojewski@intel.com Reviewed-by: "Amadeusz Sławiński" amadeuszx.slawinski@linux.intel.com Cc: Mark Brown broonie@kernel.org Cc: alsa-devel@alsa-project.org --- sound/soc/intel/avs/path.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/avs/path.c b/sound/soc/intel/avs/path.c index 05302ab705ae..adbe23a47847 100644 --- a/sound/soc/intel/avs/path.c +++ b/sound/soc/intel/avs/path.c @@ -478,7 +478,7 @@ static int avs_modext_create(struct avs_dev *adev, struct avs_path_module *mod) int ret, i;
num_pins = tcfg->generic.num_input_pins + tcfg->generic.num_output_pins; - cfg_size = sizeof(*cfg) + sizeof(*cfg->pin_fmts) * num_pins; + cfg_size = struct_size(cfg, pin_fmts, num_pins);
cfg = kzalloc(cfg_size, GFP_KERNEL); if (!cfg)
base-commit: ee3f96b164688dae21e2466a57f2e806b64e8a37
On 2023-03-01 9:46 PM, Jacob Keller wrote:
The struct avs_modcfg_ext structure has a flexible array member for the pin_fmts array, and the size should be calculated using struct_size to prevent the potential for overflow with the allocation.
Signed-off-by: Jacob Keller jacob.e.keller@intel.com Reviewed-by: Cezary Rojewski cezary.rojewski@intel.com Reviewed-by: "Amadeusz Sławiński" amadeuszx.slawinski@linux.intel.com Cc: Mark Brown broonie@kernel.org Cc: alsa-devel@alsa-project.org
I've explicitly asked for the Signed-off-by to be the last line in the tag area. Also, while I'm the author of the driver, nothing is being merged by me - Mark is the maintainer for the ASoC subsystem, so you should send messages to him and keep appropriate people/list in Cc (email's Cc list, no need for every entry to be represented by an equivalent 'Cc:' tag within a commit message simultaneously).
TLDR:
Drop both CC tags, not needed. Have both Reviewed-by _before_ Signed-off-by. Then update the email's --cc/--to so that it reflects the actual structure of the subsystem.
sound/soc/intel/avs/path.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/avs/path.c b/sound/soc/intel/avs/path.c index 05302ab705ae..adbe23a47847 100644 --- a/sound/soc/intel/avs/path.c +++ b/sound/soc/intel/avs/path.c @@ -478,7 +478,7 @@ static int avs_modext_create(struct avs_dev *adev, struct avs_path_module *mod) int ret, i;
num_pins = tcfg->generic.num_input_pins + tcfg->generic.num_output_pins;
- cfg_size = sizeof(*cfg) + sizeof(*cfg->pin_fmts) * num_pins;
cfg_size = struct_size(cfg, pin_fmts, num_pins);
cfg = kzalloc(cfg_size, GFP_KERNEL); if (!cfg)
base-commit: ee3f96b164688dae21e2466a57f2e806b64e8a37
On 3/3/2023 1:27 AM, Cezary Rojewski wrote:
On 2023-03-01 9:46 PM, Jacob Keller wrote:
The struct avs_modcfg_ext structure has a flexible array member for the pin_fmts array, and the size should be calculated using struct_size to prevent the potential for overflow with the allocation.
Signed-off-by: Jacob Keller jacob.e.keller@intel.com Reviewed-by: Cezary Rojewski cezary.rojewski@intel.com Reviewed-by: "Amadeusz Sławiński" amadeuszx.slawinski@linux.intel.com Cc: Mark Brown broonie@kernel.org Cc: alsa-devel@alsa-project.org
I've explicitly asked for the Signed-off-by to be the last line in the tag area. Also, while I'm the author of the driver, nothing is being merged by me - Mark is the maintainer for the ASoC subsystem, so you should send messages to him and keep appropriate people/list in Cc (email's Cc list, no need for every entry to be represented by an equivalent 'Cc:' tag within a commit message simultaneously).
Will fix in v2. Sorry about this, I wasn't aware what the convention was. I am used to thinking about the tags in order of when the event occurred, "I signed off that this is my work and can submit it first, then it was reviewed". The Cc tags were there because it helps me keep track of who to send the patch to but I can do that separately and drop them from the commit message.
Thanks, Jake
TLDR:
Drop both CC tags, not needed. Have both Reviewed-by _before_ Signed-off-by. Then update the email's --cc/--to so that it reflects the actual structure of the subsystem.
sound/soc/intel/avs/path.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/avs/path.c b/sound/soc/intel/avs/path.c index 05302ab705ae..adbe23a47847 100644 --- a/sound/soc/intel/avs/path.c +++ b/sound/soc/intel/avs/path.c @@ -478,7 +478,7 @@ static int avs_modext_create(struct avs_dev *adev, struct avs_path_module *mod) int ret, i;
num_pins = tcfg->generic.num_input_pins + tcfg->generic.num_output_pins;
- cfg_size = sizeof(*cfg) + sizeof(*cfg->pin_fmts) * num_pins;
cfg_size = struct_size(cfg, pin_fmts, num_pins);
cfg = kzalloc(cfg_size, GFP_KERNEL); if (!cfg)
base-commit: ee3f96b164688dae21e2466a57f2e806b64e8a37
On Wed, 01 Mar 2023 12:46:28 -0800, Jacob Keller wrote:
The struct avs_modcfg_ext structure has a flexible array member for the pin_fmts array, and the size should be calculated using struct_size to prevent the potential for overflow with the allocation.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: Intel: avs: Use struct_size for struct avs_modcfg_ext size commit: c9ef0fee3bdf8197538aadc728e475fceba113bb
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
participants (3)
-
Cezary Rojewski
-
Jacob Keller
-
Mark Brown