[PATCH] firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files
Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files.
In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing.
Signed-off-by: Richard Fitzgerald rf@opensource.cirrus.com Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs") --- drivers/firmware/cirrus/cs_dsp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/cirrus/cs_dsp.c b/drivers/firmware/cirrus/cs_dsp.c index d2aa0980ed78..0a504a3c4375 100644 --- a/drivers/firmware/cirrus/cs_dsp.c +++ b/drivers/firmware/cirrus/cs_dsp.c @@ -1166,7 +1166,7 @@ static inline void cs_dsp_coeff_parse_alg(struct cs_dsp *dsp, const u8 **data,
blk->id = le32_to_cpu(raw->id); blk->name = raw->name; - blk->name_len = strlen(raw->name); + blk->name_len = strnlen(raw->name, ARRAY_SIZE(raw->name)); blk->ncoeff = le32_to_cpu(raw->ncoeff); break; default: @@ -1199,7 +1199,7 @@ static inline void cs_dsp_coeff_parse_coeff(struct cs_dsp *dsp, const u8 **data, blk->offset = le16_to_cpu(raw->hdr.offset); blk->mem_type = le16_to_cpu(raw->hdr.type); blk->name = raw->name; - blk->name_len = strlen(raw->name); + blk->name_len = strnlen(raw->name, ARRAY_SIZE(raw->name)); blk->ctl_type = le16_to_cpu(raw->ctl_type); blk->flags = le16_to_cpu(raw->flags); blk->len = le32_to_cpu(raw->len);
On 08/07/2024 15:48, Richard Fitzgerald wrote:
Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files.
In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing.
Signed-off-by: Richard Fitzgerald rf@opensource.cirrus.com Fixes: f6bc909e7673 ("firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs")
Don't take this. It applies to 6.11 but not to 6.10. I'll try to sort out one that applies to new and old code, or send separate 6.11 and backport versions.
Sorry about that.
On Mon, Jul 08, 2024 at 04:00:07PM +0100, Richard Fitzgerald wrote:
Don't take this. It applies to 6.11 but not to 6.10. I'll try to sort out one that applies to new and old code, or send separate 6.11 and backport versions.
Sorry about that.
git seemed to be able to figure out the context for 6.10 (I apply everything with am -3).
On 08/07/2024 16:05, Mark Brown wrote:
On Mon, Jul 08, 2024 at 04:00:07PM +0100, Richard Fitzgerald wrote:
Don't take this. It applies to 6.11 but not to 6.10. I'll try to sort out one that applies to new and old code, or send separate 6.11 and backport versions.
Sorry about that.
git seemed to be able to figure out the context for 6.10 (I apply everything with am -3).
Oh, I read this just after I'd sent a V2. You can ignore my V2 if you've got it to apply (it's the same patch but with a couple of conflicting lines dropped from the context)
On Mon, Jul 08, 2024 at 04:22:46PM +0100, Richard Fitzgerald wrote:
On 08/07/2024 16:05, Mark Brown wrote:
git seemed to be able to figure out the context for 6.10 (I apply everything with am -3).
Oh, I read this just after I'd sent a V2. You can ignore my V2 if you've got it to apply (it's the same patch but with a couple of conflicting lines dropped from the context)
Yeah, no worries - git seemed to cope fine.
On Mon, 08 Jul 2024 15:48:55 +0100, Richard Fitzgerald wrote:
Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files.
In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files commit: 680e126ec0400f6daecf0510c5bb97a55779ff03
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 (2)
-
Mark Brown -
Richard Fitzgerald