linux-kernel - Re: [PATCH v4 1/2] string: Add load_unaligned_zeropad() code path to sized

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: <20250403221522.328b174b@pumpkin>
Date: Thu, 3 Apr 2025 22:15:22 +0100
From: David Laight <david.laight.linux@...il.com>
To: Peter Collingbourne <pcc@...gle.com>
Cc: Catalin Marinas <catalin.marinas@....com>, Alexander Viro
 <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan Kara
 <jack@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>, Kees Cook
 <kees@...nel.org>, Andy Shevchenko <andy@...nel.org>, Andrey Konovalov
 <andreyknvl@...il.com>, Mark Rutland <mark.rutland@....com>,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-hardening@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 stable@...r.kernel.org
Subject: Re: [PATCH v4 1/2] string: Add load_unaligned_zeropad() code path
 to sized_strscpy()

On Wed, 2 Apr 2025 17:08:51 -0700
Peter Collingbourne <pcc@...gle.com> wrote:

> On Wed, Apr 2, 2025 at 1:10 PM Catalin Marinas <catalin.marinas@....com> wrote:
..
> > Reading across tag granule (but not across page boundary) and causing a
> > tag check fault would result in padding but we can live with this and
> > only architectures that do MTE-style tag checking would get the new
> > behaviour.  
> 
> By "padding" do you mean the extra (up to sizeof(unsigned long)) nulls
> now written to the destination? It seems unlikely that code would
> deliberately depend on the nulls not being written, the number of
> nulls written is not part of the documented interface contract and
> will vary right now depending on how close the source string is to a
> page boundary. If code is accidentally depending on nulls not being
> written, that's almost certainly a bug anyway (because of the page
> boundary thing) and we should fix it if discovered by this change.

There was an issue with one of the copy routines writing beyond
the expected point in a destination buffer.
I can't remember the full details, but it would match strscpy().

	David