Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <CAFLxGvwpuxKF4UWdsULwQWo7kgVLMNHC=77dN+w-A0a6avrAXA@mail.gmail.com>
References: <CAN1fySViLgrLAHHfTHMef-Bkh73kUHKP-ava6TbgALeSE4LfFw@mail.gmail.com>
 <CAFLxGvwpuxKF4UWdsULwQWo7kgVLMNHC=77dN+w-A0a6avrAXA@mail.gmail.com>
From:   Samuel Dionne-Riel <samuel@dionne-riel.com>
Date:   Wed, 13 Feb 2019 19:41:18 -0500
Message-ID: <CAN1fySXjLUYFw2JGQQ5xxqjX+6kygzqgUc6Oj-sbtq=ZjgfLTA@mail.gmail.com>
Subject: Re: Userspace regression in LTS and stable kernels
To:     Richard Weinberger <richard.weinberger@gmail.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        graham@grahamc.com, Oleg Nesterov <oleg@redhat.com>,
        Kees Cook <keescook@chromium.org>, mhocko@suse.com,
        Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Thanks for CC'ing relevant folks.

On 13/02/2019, Richard Weinberger <richard.weinberger@gmail.com> wrote:
> [CC'in relevant folks]
>
> On Thu, Feb 14, 2019 at 12:19 AM Samuel Dionne-Riel
> <samuel@dionne-riel.com> wrote:
>>
>> Here is an example shebang causing an issue:
>>
>> #! /nix/store/mbwav8kz8b3y471wjsybgzw84mrh4js9-perl-5.28.1/bin/perl
>> -I/nix/store/x6yyav38jgr924nkna62q3pkp0dgmzlx-perl5.28.1-File-Slurp-9999=
.25/lib/perl5/site_perl
>> -I/nix/store/ha8v67sl8dac92r9z07vzr4gv1y9nwqz-perl5.28.1-Net-DBus-1.1.0/=
lib/perl5/site_perl
>> -I/nix/store/dcrkvnjmwh69ljsvpbdjjdnqgwx90a9d-perl5.28.1-XML-Parser-2.44=
/lib/perl5/site_perl
>> -I/nix/store/rmji88k2zz7h4zg97385bygcydrf2q8h-perl5.28.1-XML-Twig-3.52/l=
ib/perl5/site_perl
>
> This this ever work correctly? It is longer than BINPRM_BUF_SIZE.
>

Yes, this is longer than BINPRM_BUF_SIZE. This worked when the
interpreter knew to re-read the shebang, which among other
interpreters, perl did.

https://perl5.git.perl.org/perl.git/blob/04db542212fdad3a62f13afe741c99028f=
4bf799:/toke.c#l5524

>> (The shebang was artificially wrapped spaces replaced by newlines)
>>
>> Another contributor tracked the regression it to commit
>> 8099b047ecc431518b9bb6bdbba3549bbecdc343 in the 5.0-rc* tree.
>>
>> I bring no particular fix to the issue, but I believe it should at
>> least be fast-tracked to a revert for the stable and LTS branches, and
>> since 5.0 might drop soon, a solution worked on, or possibly a revert
>> until one is figured out.
>
> Your shebang line exceeds BINPRM_BUF_SIZE.
> Before the said commit the kernel silently truncated the shebang line
> (and corrupted it),
> now it tells the user that the line is too long.
>

Yes, the shebang line exceeds BINPRM_BUF_SIZE.

Before, the interpreter was still used (assuming it wasn't cut by the
length), and the interpreter was free to re-read the shebang if
desired.

With the new behaviour, instead of executing the interpreter with a
possibly truncated command line, the default script interpreter is
used, meaning that the perl script is being interpreted by the wrong
interpreter, giving copious amounts of irrelevant errors. This is not
telling the user that the line is too long.

This provably breaks the userland as under 4.14.98 the perl
interpreter is used when running the script, and under 4.14.99 bash is
used when running the script.

For a given script with a shebang of #!(124*A)ZBBB:

The behaviour as of before the regression:

sh: ./foolish: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ:
bad interpreter: No such file or directory

As expected, it cuts the shebang.

The behaviour following the change is the script ends up being
executed by the shell interpreter, as if there was no shebang, and +x.

Quoted from `man 3 exec`

> If the header of a file isn't recognized (the attempted execve(2) failed =
with the error ENOEXEC), these functions will execute the shell (/bin/sh) w=
ith the path of the file as its first argument. (If this attempt fails, no =
further searching is done.)

The now returned ENOEXEC might be "more right", but changes the
semantics of a truncated shebang.

Here I am not debating the validity of using a truncated shebang, but
showing that the userspace behaviour changed in an unexpected and
breaking behaviour.

Am I under a wrong assumption that the kernel shouldn't break userspace?

--=20
=E2=80=94 Samuel Dionne-Riel