linux-kernel - Re: [PATCH v2] ASoC: Intel: avs: Fix potential buffer overflow by snprintf()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2025111313-submerge-strength-ada6@gregkh>
Date: Thu, 13 Nov 2025 08:24:14 -0500
From: Greg KH <gregkh@...uxfoundation.org>
To: Cezary Rojewski <cezary.rojewski@...el.com>
Cc: liam.r.girdwood@...ux.intel.com, peter.ujfalusi@...ux.intel.com,
	yung-chuan.liao@...ux.intel.com, ranjani.sridharan@...ux.intel.com,
	kai.vehmanen@...ux.intel.com, pierre-louis.bossart@...ux.dev,
	broonie@...nel.org, perex@...ex.cz, tiwai@...e.com,
	amadeuszx.slawinski@...ux.intel.com, sakari.ailus@...ux.intel.com,
	khalid@...nel.org, shuah@...nel.org, david.hunter.linux@...il.com,
	linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, hariconscious@...il.com
Subject: Re: [PATCH v2] ASoC: Intel: avs: Fix potential buffer overflow by
 snprintf()

On Thu, Nov 13, 2025 at 09:46:12AM +0100, Cezary Rojewski wrote:
> On 2025-11-12 8:20 PM, Greg KH wrote:
> > On Wed, Nov 12, 2025 at 11:48:51PM +0530, hariconscious@...il.com wrote:
> > > From: HariKrishna Sagala <hariconscious@...il.com>
> > > 
> > > 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).
> > 
> > unrealistic == impossible
> > 
> > So why make this change at all?
> 
> The problem will never occur in production-scenario given the AudioDSP
> firmware limitation - max ~10 probe-point entries so, the built string will
> be far away from 4K_SZ bytes.
> 
> If the verdict is: ignore the recommendation as the problem is unrealistic,
> I'm OK with that. Typically though I'd prefer to stick to the
> recommendations.

That's fine, but don't claim that it fixes a buffer overflow when that
is NOT what this is doing at all.

> > > This patch replaces it with a safer version, scnprintf() for papering
> > > over such a potential issue.
> > 
> > Don't "paper over", actually fix real things.
> > 
> > 
> > > Link: https://github.com/KSPP/linux/issues/105
> > > 'Fixes: 5a565ba23abe ("ASoC: Intel: avs: Probing and firmware tracing
> > > over debugfs")'
> > 
> > No, this is not a "fix".
> 
> The patch isn't worded well, that's clear.
> While the patch is an outcome of static-analysis, isn't it good to have
> 'Fixes:' to point out the offending commit regardless?

No, it is not "fixing" anything.  Please don't claim that it does.  It
is "just" a code transformation to get rid of an api that some people do
not like.

thanks,

greg k-h