linux-kernel - Re: Userspace regression in LTS and stable kernels

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]

Date:   Wed, 13 Feb 2019 16:41:30 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Richard Weinberger <richard.weinberger@...il.com>
Cc:     Samuel Dionne-Riel <samuel@...nne-riel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        graham@...hamc.com, Oleg Nesterov <oleg@...hat.com>,
        Michal Hocko <mhocko@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Userspace regression in LTS and stable kernels

On Wed, Feb 13, 2019 at 3:36 PM Richard Weinberger
<richard.weinberger@...il.com> wrote:
>
> [CC'in relevant folks]
>
> On Thu, Feb 14, 2019 at 12:19 AM Samuel Dionne-Riel
> <samuel@...nne-riel.com> wrote:
> >
> > Hi,
> >
> > I am posting as a representative of the NixOS Linux distribution,
> > about a userspace regression on 5.0-rc* which recently was backported
> > to the 4.14.99, 4.19.21 and 4.20.8 current LTS and stable versions.
> > The issue has been reported to the bug tracker, bug 202497, but seems
> > to have gone unnoticed by the maintainers.
> >
> > The issue seems to break userspace for long-standing patterns in the
> > NixOS distribution, with regards to use of the shebangs.
> >
> > 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/lib/perl5/site_perl
>
> This this ever work correctly? It is longer than BINPRM_BUF_SIZE.
>
> > (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.

Yeah, it looks like it just truncates:

$ cat /nix/store/mbwav8kz8b3y471wjsybgzw84mrh4js9-perl-5.28.1/bin/perl
#!/usr/bin/perl
print "Arg # 0 : $0\n";
$counter = 1;
foreach my $a (@ARGV) {
        print "Arg # $counter : $a\n";
        $counter++;
}
$ cat test.pl
#! /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/lib/perl5/site_perl
print "I am the script\n";

4.20.7:
$ ./test.pl
Arg # 0 : /nix/store/mbwav8kz8b3y471wjsybgzw84mrh4js9-perl-5.28.1/bin/perl
Arg # 1 : -I/nix/store/x6yyav38jgr924nkna62q3pkp0dgmzlx-perl5.28.1-Fi
Arg # 2 : ./test.pl

4.20.8:
$ ./test.pl
Error: no such file "I am the script\n"

(My shell seems to fall back to direct shell execution)

Since this is breaking existing userspace, we should probably switch
back to the truncation, but do a WARN_ONCE or something so there's a
visible hint _somewhere_ about the (long standing) issue? What do you
think Oleg?

-Kees

-- 
Kees Cook