[Toybox] [PATCH] tar: fix heap buffer overrun.

[enh]

On Thu, Oct 15, 2020 at 9:22 PM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 10/15/20 7:45 PM, enh wrote:
> > On Thu, Oct 15, 2020 at 5:21 PM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 10/14/20 3:21 PM, enh wrote:
> >>> i've sent a new fix that just touches dirtree_path() so that it always
> >>> honors the size request again.
> >>
> >> Applied, and then cosmetically fiddled with because I do that.
> >>
> >>>> but I leave for the airport to fly back to Japan in 2 hours. (Part of the
> >>>> reason I've been so distracted lately, it's not JUST focusing on sh.c. :)
> >>>>
> >>>>> Caught by ASan.
> >>>>
> >>>> Operating on what path?
> >>>
> >>> the new patch's commit message makes it clearer that you can reproduce
> >>> this with the existing tar tests, as long as you `export ASAN=1`.
> >>> (would we need extra docker dependencies, or should we just turn that
> >>> on for the github CI?)
> >>
> >> No idea.
> >
> > yeah, i was hoping our github CI expert would chime in :-)
> >
> >> I mentioned the ndk not working for this becuase of the need to build --static
> >> to run anything on a system that doesn't have bionic installed in /lib, and asan
> >> not working --static.
> >>
> >> I can install llvm 7 through the devuan apt-get (may 2019), but 11 just shipped
> >> and they don't have debian binaries, just ubuntu. MIGHT work? Not looking
> >> forward to trying to build that from source, it's really brittle last I
> >> checked... Ah, maybe I can follow:
> >>
> >>   http://www.linuxfromscratch.org/blfs/view/svn/general/llvm.html
> >>
> >> Um... is ninja part of cmake now? It lists cmake as a dependency but does not
> >> list ninja? Did they add ninja to the 10.x base?
> >>
> >>   http://www.linuxfromscratch.org/lfs/view/stable/chapter08/ninja.html
> >>
> >> yes they did. Lovely...
> >>
> >> Anyway, question: is llvm 7 likely to be enough, or should I try compiling llvm
> >> from source to poke at this asan stuff?
> >
> > debian testing seems to have llvm 9 atm, and that's what i used, but,
> > yes, asan's been stable for a while now so i'd expect 7 should be
> > fine.
>
> "After this operation, 562 MB of additional disk space will be used." Sigh. On
> aboriginal linux I had a gcc install in 14 megs and 11 of that was /usr/include.
> Why did they choose to write this in c++ again?

remember clang is always a cross-compiler, so one clang == lots of gccs.

> So I installed llvm-7 and afterwards did not have either a "clang" or an "llvm"
> in the $PATH. So I installed clang-7 and still don't. I think I'm washing my
> hands of debian's packaging of llvm because it DOESN'T WORK. (I now very vaguely
> recall trying this before and uninstalling it again for this reason.)

works for me on debian:

~$ dpkg -S `which clang`
clang: /usr/bin/clang
~$ update-alternatives --list cc
/usr/bin/clang
/usr/bin/gcc

> I need to poke at LFS 10 anyway. I've mostly got mkroot back together and
> booting again with toysh. Still need function() support and to finish
> implementing the "source" command, and get the tests passing and turn shtest.txt
> into more tests, but it's almost ready to start throwing real stuff at? What do
> I need...
>
> Nope, do_math() is still a stub so no $(( )) yet. And I should probably do [[ ]]
> because some build script is likely to use that. And that TODO about \escapes in
> backquotes is probably gonna bite. (Yeah I still need to do array variable
> support but I can wait for something to break needing it, same for shopt
> nocasematch and so on.) Signal handling at least needs to be stubbed in so
> "trap" isn't an unknown command, but them I've got a chunk of job control
> pluming implemented already. I don't strictly need to do command line editing
> and history before trying to build LFS with it but you REALLY notice it's
> missing using it interactively...
>
> But... huh. It just went over 3500 lines and I'm sad about that, and yet it's
> actually most of the way there? Ish? Sort of? Not THIS release, and plenty of
> polishing stuff still to do, plus the PILE of bugs any real load is bound to
> squeeze out...
>
> Rob