linux-kernel - Re: [PATCH v3] kdb: Replace deprecated strcpy() with strscpy() and memcpy()

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: <72F30E3D-2887-4494-B58C-2042AC880C1B@linux.dev>
Date: Fri, 15 Aug 2025 15:16:27 +0200
From: Thorsten Blum <thorsten.blum@...ux.dev>
To: Daniel Thompson <daniel@...cstar.com>
Cc: Jason Wessel <jason.wessel@...driver.com>,
 Daniel Thompson <danielt@...nel.org>,
 Douglas Anderson <dianders@...omium.org>,
 Nir Lichtman <nir@...htman.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Yuran Pereira <yuran.pereira@...mail.com>,
 linux-hardening@...r.kernel.org,
 kgdb-bugreport@...ts.sourceforge.net,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] kdb: Replace deprecated strcpy() with strscpy() and
 memcpy()

On 15. Aug 2025, at 13:40, Daniel Thompson wrote:
> On Fri, Aug 15, 2025 at 01:28:01PM +0200, Thorsten Blum wrote:
>> Hi Daniel,
>> 
>>> On 15. Aug 2025, at 10:57, Daniel Thompson wrote:
>>> Sorry but a strscpy() where the length of the destination buffer has
>>> been calculated from the source string is way too much of a red flag
>>> for me.
>>> 
>>> Put another way if there are "no functional changes intended" then there
>>> cannot possibly be any security benefit from replacing the "unsafe"
>>> strcpy() with the "safe" strscpy(). Likewise abusing the destination
>>> length argument to truncate a string makes the code shorter but *not*
>>> clearer because it's too easy to misread.
>> 
>> Deliberately truncating the source using strscpy() is a valid use case.
>> strscpy() allows the size argument to be smaller than the destination
>> buffer, so this is an intended use of the size argument, not an abuse.
> 
> Sorry, I didn't phrase that especially well. I regard the abuse to be
> deriving the length of the destination buffer exclusively from the
> state of the source buffer.
> 
> As mentioned, it would be much cleaner to eliminate the string copy entirely
> than to translate it into something so similar to the original strcpy().

Something like this?

char *kdb_strdup_dequote(const char *str, gfp_t type)
{
	size_t len = strlen(str);
	char *s;

	if (str[0] == '"') {
		/* skip leading quote */
		len--;
		str++;

		if (len > 0 && str[len - 1] == '"')
			len--; /* skip trailing quote */
       }

	len++; /* add space for NUL terminator */

	s = kmalloc(len, type);
	if (!s)
		return NULL;
	strscpy(s, str, len);
	return s;
}

This should probably be a separate patch, right?

Thanks,
Thorsten