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] [thread-next>] [day] [month] [year] [list]

Message-ID: <bc479d42-af01-466f-b066-1da9a99b29bb@intel.com>
Date: Thu, 13 Nov 2025 09:46:12 +0100
From: Cezary Rojewski <cezary.rojewski@...el.com>
To: Greg KH <gregkh@...uxfoundation.org>
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 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.

> 
>> 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?