linux-kernel - Re: [PATCH v2] exec: make printable macro more concise

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: <CAHk-=wiMEpPZYDeF5ak8FToB_fw7pfjKhuJAcjLpjqMfCvvB7g@mail.gmail.com>
Date: Sat, 16 Nov 2024 08:49:39 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Nir Lichtman <nir@...htman.org>, ebiederm@...ssion.com, kees@...nel.org, 
	brauner@...nel.org, jack@...e.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] exec: make printable macro more concise

On Fri, 15 Nov 2024 at 23:28, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Now, whether that logics makes sense is a separate story;
> that's before my time (1.3.60), so...

Bah. The whole ctype stuff is a mess, partly because it's
fundamentally a broken concept and depends on locale.

The original ctype array was US-ASCII only, and at some point in the
random past it got changed to be based on Latin1. Maybe indeed 1.3.60
as you say, I didn't go digging around.

And Latin1 is not only what I used to use, it's the "low range of
unicode". So it makes *some* sense, but not a whole lot.

It might be good to go back to US-ASCII just as a true lowest common
denominator, because people who use the ctype macros almost certainly
don't actually do it on unicode characters, they do it on bytes, and
then UTF-8 will not actually DTRT with anything but US-ASCII anyway.

And this fs/exec.c code is really confused. It explicitly doesn't use
our ctype, probably exactly *because* of high-bit issues, but then it
calls '\t' and '\n' is "printable", makes little sense.

What that code seems to basically want to do is to check that
'bprm->buf' is some binary data, not text, and using "printable()" as
a name for that is actively misleading and wrong.

So I really think that all it does is try to protect from even
*trying* to execute a text-file or script as a binary.

Anyway, the fs/exec.c "printable()" code most definitely shouldn't use
the ctype stuff. I'm not sure it should exist at all, and if it should
exist it probably should be renamed. Because it has *nothing* to do
with "isprint()".

> Looks like module-init-tools used to put (completely useless by that time,
> due to the printf format change from %hd to %04x) aliases for binfmt_aout
> into /etc/modprobe.d/aliases.conf:
>         alias binfmt-204 binfmt_aout
>         alias binfmt-263 binfmt_aout
>         alias binfmt-264 binfmt_aout
>         alias binfmt-267 binfmt_aout
>         alias binfmt-387 binfmt_aout
> until 2011, when it had been put out of its misery.

What a crock. Yeah, that code seems to be entirely dead.

The "two first bytes" thing only makes sense for a.out, and those
numbers are odd. The first four ones make sense (QMAGIC, OMAGIC,
NMAGIC and ZMAGIC respectively), but 387 doesn't even seem to match
any a.out magic number

Oh, it's CMAGIC. Which is a core file. That you should never try to
execute. So it's just insane.

Very strange.

Anyway, a.out support is dead, so I think this code is pure historical
leftovers and should be removed.

           Linus