linux-kernel - Re: [RFC v5 6/7] sprintf: Add [v]sprintf

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: <28c8689c7976b4755c0b5c2937326b0a3627ebf6.camel@gmail.com>
Date: Fri, 11 Jul 2025 08:05:38 +0200
From: Martin Uecker <ma.uecker@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>, Alejandro Colomar
	 <alx@...nel.org>
Cc: linux-mm@...ck.org, linux-hardening@...r.kernel.org, Kees Cook
 <kees@...nel.org>, Christopher Bazley <chris.bazley.wg14@...il.com>, shadow
 <~hallyn/shadow@...ts.sr.ht>, linux-kernel@...r.kernel.org, Andrew Morton
 <akpm@...ux-foundation.org>, kasan-dev@...glegroups.com, Dmitry Vyukov
 <dvyukov@...gle.com>, Alexander Potapenko <glider@...gle.com>, Marco Elver
 <elver@...gle.com>, Christoph Lameter <cl@...ux.com>, David Rientjes
 <rientjes@...gle.com>, Vlastimil Babka <vbabka@...e.cz>, Roman Gushchin
 <roman.gushchin@...ux.dev>, Harry Yoo <harry.yoo@...cle.com>, Andrew
 Clayton <andrew@...ital-domain.net>, Rasmus Villemoes
 <linux@...musvillemoes.dk>,  Michal Hocko <mhocko@...e.com>, Al Viro
 <viro@...iv.linux.org.uk>, Sam James <sam@...too.org>, Andrew Pinski
 <pinskia@...il.com>
Subject: Re: [RFC v5 6/7] sprintf: Add [v]sprintf_array()

Am Donnerstag, dem 10.07.2025 um 14:58 -0700 schrieb Linus Torvalds:
> On Thu, 10 Jul 2025 at 14:31, Alejandro Colomar <alx@...nel.org> wrote:
> > 
> > These macros are essentially the same as the 2-argument version of
> > strscpy(), but with a formatted string, and returning a pointer to the
> > terminating '\0' (or NULL, on error).
> 
> No.
> 
> Stop this garbage.
> 
> You took my suggestion, and then you messed it up.
> 
> Your version of sprintf_array() is broken. It evaluates 'a' twice.
> Because unlike ARRAY_SIZE(), your broken ENDOF() macro evaluates the
> argument.
> 
> And you did it for no reason I can see. You said that you wanted to
> return the end of the resulting string, but the fact is, not a single
> user seems to care, and honestly, I think it would be wrong to care.
> The size of the result is likely the more useful thing, or you could
> even make these 'void' or something.
> 
> But instead you made the macro be dangerous to use.
> 
> This kind of churn is WRONG. It _looks_ like a cleanup that doesn't
> change anything, but then it has subtle bugs that will come and bite
> us later because you did things wrong.
> 
> I'm NAK'ing all of this. This is BAD. Cleanup patches had better be
> fundamentally correct, not introduce broken "helpers" that will make
> for really subtle bugs.
> 
> Maybe nobody ever ends up having that first argument with a side
> effect. MAYBE. It's still very very wrong.
> 
>                 Linus

What I am puzzled about is that - if you revise your string APIs -,
you do not directly go for a safe abstraction that combines length
and pointer and instead keep using these fragile 80s-style string
functions and open-coded pointer and size computations that everybody
gets wrong all the time.

String handling could also look like this:


https://godbolt.org/z/dqGz9b4sM

and be completely bounds safe.

(Note that those function abort() on allocation failure, but this
is an unfinished demo and also not for kernel use. Also I need to
rewrite this using string views.)


Martin