linux-kernel - Re: [PATCH 1/1] fs/qnx6: Fix building with GCC 15

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: <20241006200046.GF4017910@ZenIV>
Date: Sun, 6 Oct 2024 21:00:46 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: David Laight <David.Laight@...lab.com>
Cc: Brahmajit Das <brahmajit.xyz@...il.com>,
	"brauner@...nel.org" <brauner@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] fs/qnx6: Fix building with GCC 15

On Sun, Oct 06, 2024 at 07:38:07PM +0000, David Laight wrote:
> ...
> > would explain what was really going on - the point is not to make gcc STFU, it's
> > to make the code more straightforward.  The warning is basically "it smells
> > somewhat fishy around >here<, might be worth taking a look".  And yes, it turned
> > out to be fishy; minimal "make it STFU" would be to strip those NULs from
> > the initializers (i.e. just go for static char match_root[2][3] = {".", ".."}; -
> > an array initializer is zero-padded if it's shorter than the array), but that
> > wasn't the only, er, oddity in that code.
> 
> Indeed - looks like it is checking that the first two directory entries
> are "." and ".." in about the most complex way possible.
> 
> I have vague recollections on some code that ignored the first two entries
> because they 'must be "." and ".."' - and then failed because some filesystem
> (and I can't even remember the O/S) didn't meet its expectations!
> 
> A simple:
> 	if (strcmp(dir_entry[0].de_fname, ".") || strcmp(dir_entry[1].de_fname, ".."))
> 		error = 1;
> would suffice.

memcmp(), please.  strcmp() is _not_ guaranteed to be safe without both being
NUL-terminated; yes, compiler will almost simplify that in case when one of
the arguments is a string literal, but it's better to do straight memcmp() in
this case.  It's not worth trying to be fancy there...