[PATCH 0/3] ASoC: Fix theoretical buffer overflow by snprintf()

[PATCH 0/3] ASoC: Fix theoretical buffer overflow by snprintf()

[Takashi Iwai]

Hi,

this is a patch series to paper over the theoretical buffer overflow
that might be caused by snprintf().  snprintf() is notorious for its
behavior and the usage of a safer version, scnprintf(), is
recommended.


Takashi

===

Takashi Iwai (3):
  ASoC: Intel: avs: Fix potential buffer overflow by snprintf()
  ASoC: SOF: debug: Fix potential buffer overflow by snprintf()
  ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()

 sound/soc/intel/avs/pcm.c | 4 ++--
 sound/soc/sof/debug.c     | 6 +++---
 sound/soc/sof/intel/hda.c | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.35.3

[PATCH 1/3] ASoC: Intel: avs: Fix potential buffer overflow by snprintf()

[Takashi Iwai]

snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in a buffer
overflow (although it's unrealistic).

This patch replaces it with a safer version, scnprintf() for papering
over such a potential issue.

Fixes: f1b3b320bd65 ("ASoC: Intel: avs: Generic soc component driver")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/soc/intel/avs/pcm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/intel/avs/pcm.c b/sound/soc/intel/avs/pcm.c
index f21b0cdd3206..8fe5917b1e26 100644
--- a/sound/soc/intel/avs/pcm.c
+++ b/sound/soc/intel/avs/pcm.c
@@ -636,8 +636,8 @@ static ssize_t topology_name_read(struct file *file, char __user *user_buf, size
 	char buf[64];
 	size_t len;
 
-	len = snprintf(buf, sizeof(buf), "%s/%s\n", component->driver->topology_name_prefix,
-		       mach->tplg_filename);
+	len = scnprintf(buf, sizeof(buf), "%s/%s\n", component->driver->topology_name_prefix,
+			mach->tplg_filename);
 
 	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
 }
-- 
2.35.3

[PATCH 2/3] ASoC: SOF: debug: Fix potential buffer overflow by snprintf()

[Takashi Iwai]

snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in the buffer
overflow (although it's unrealistic).

This patch replaces with a safer version, scnprintf() for papering
over such a potential issue.

Fixes: 5b10b6298921 ("ASoC: SOF: Add `memory_info` file to debugfs")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/soc/sof/debug.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sof/debug.c b/sound/soc/sof/debug.c
index c5d797e97c02..d9a3ce7b69e1 100644
--- a/sound/soc/sof/debug.c
+++ b/sound/soc/sof/debug.c
@@ -252,9 +252,9 @@ static int memory_info_update(struct snd_sof_dev *sdev, char *buf, size_t buff_s
 	}
 
 	for (i = 0, len = 0; i < reply->num_elems; i++) {
-		ret = snprintf(buf + len, buff_size - len, "zone %d.%d used %#8x free %#8x\n",
-			       reply->elems[i].zone, reply->elems[i].id,
-			       reply->elems[i].used, reply->elems[i].free);
+		ret = scnprintf(buf + len, buff_size - len, "zone %d.%d used %#8x free %#8x\n",
+				reply->elems[i].zone, reply->elems[i].id,
+				reply->elems[i].used, reply->elems[i].free);
 		if (ret < 0)
 			goto error;
 		len += ret;
-- 
2.35.3

[PATCH 3/3] ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()

[Takashi Iwai]

snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in the buffer
overflow (although it's unrealistic).

This patch replaces with a safer version, scnprintf() for papering
over such a potential issue.

Fixes: 29c8e4398f02 ("ASoC: SOF: Intel: hda: add extended rom status dump to error log")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/soc/sof/intel/hda.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c
index 8639ea63a10d..6d4ecbe14adf 100644
--- a/sound/soc/sof/intel/hda.c
+++ b/sound/soc/sof/intel/hda.c
@@ -574,7 +574,7 @@ static void hda_dsp_dump_ext_rom_status(struct snd_sof_dev *sdev, const char *le
 	chip = get_chip_info(sdev->pdata);
 	for (i = 0; i < HDA_EXT_ROM_STATUS_SIZE; i++) {
 		value = snd_sof_dsp_read(sdev, HDA_DSP_BAR, chip->rom_status_reg + i * 0x4);
-		len += snprintf(msg + len, sizeof(msg) - len, " 0x%x", value);
+		len += scnprintf(msg + len, sizeof(msg) - len, " 0x%x", value);
 	}
 
 	dev_printk(level, sdev->dev, "extended rom status: %s", msg);
-- 
2.35.3

Re: [PATCH 1/3] ASoC: Intel: avs: Fix potential buffer overflow by snprintf()

[Cezary Rojewski]

On 2022-08-01 6:54 PM, Takashi Iwai wrote:
> snprintf() returns the would-be-filled size when the string overflows
> the given buffer size, hence using this value may result in a buffer
> overflow (although it's unrealistic).
> 
> This patch replaces it with a safer version, scnprintf() for papering
> over such a potential issue.
> 
> Fixes: f1b3b320bd65 ("ASoC: Intel: avs: Generic soc component driver")
> Signed-off-by: Takashi Iwai <tiwai@suse.de>

Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>

Re: [PATCH 0/3] ASoC: Fix theoretical buffer overflow by snprintf()

[Mark Brown]

On Mon, 1 Aug 2022 18:54:17 +0200, Takashi Iwai wrote:
> this is a patch series to paper over the theoretical buffer overflow
> that might be caused by snprintf().  snprintf() is notorious for its
> behavior and the usage of a safer version, scnprintf(), is
> recommended.
> 
> 
> Takashi
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/3] ASoC: Intel: avs: Fix potential buffer overflow by snprintf()
      commit: ca3b7b9dc9bc1fa552f4697b7cccfa0258a44d00
[2/3] ASoC: SOF: debug: Fix potential buffer overflow by snprintf()
      commit: 1eb123ce985e6cf302ac6e3f19862d132d86fa8f
[3/3] ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()
      commit: 94c1ceb043c1a002de9649bb630c8e8347645982

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