[Toybox] ASAN errors in toysh

[Eric Roshan-Eisner]

Also a segfault when sourcing a broken file, somewhere in the
setlongjmp rebound.
$ echo for > for.sh; toybox sh -c 'source for.sh'

On Fri, May 24, 2024 at 7:10 PM Eric Roshan-Eisner <eric.d.eisner at gmail.com>
wrote:

> Some new ones:
> $ toybox sh -c '['
> $ toybox sh -c '${\'
> $ toybox sh -c '(0;0)'
> $ toybox sh -c '$(($(<`0\'
> $ toybox sh -c 'for i in;do 0;done&'
> $ toybox sh -c 'f(){ f;};f <f'
> $ toybox sh -c '{{,},,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,'
> $ toybox sh -c $'\n$\'\375\375\375\375\''
>
> I'll keep running the fuzzer over the weekend.
>
> On Mon, Jan 9, 2023 at 8:39 AM Eric Roshan-Eisner <eric.d.eisner at gmail.com>
> wrote:
>
>> Thanks for the quick response. Feel free to ignore these reports until
>> after you cut the release ;).
>>
>> With the new code it could branch out and find some new ones:
>> $ toybox sh -c 'for;i 0'
>> $ toybox sh -c '`<`'
>> $ toybox sh -c '"$'"'"'"' # mostly shell escape; it's just " $ ' "
>> without spaces
>>
>>
>>
>> On Sun, Jan 8, 2023 at 12:04 PM Rob Landley <rob at landley.net> wrote:
>>
>>> On 1/8/23 01:41, Eric Roshan-Eisner wrote:
>>> > I ran the shell through the afl++ fuzzer, and it split out a few
>>> different ASAN
>>> > failures for simple inputs:
>>>
>>> Yeah, I'm grinding through the existing ones the test suite triggers
>>> right now,
>>> but since it's in pending I'm trying not to (further) hold up the 0.8.9
>>> release
>>> for it.
>>>
>>> > heap-buffer-overflow:
>>> > $ toybox sh -c '$'
>>>
>>> Fixed, added test.
>>>
>>> > $ toybox sh -c '+()'
>>>
>>> Yeah, it does the same for +(.) too. The wildcard_path() plumbing's still
>>> unfinished. The basics are sketched out but I need to cycle back to it.
>>> (There's
>>> a reason it's still in pending...)
>>>
>>> Sigh, is there any way to get ASAN to stop showing the useless "shadow
>>> bytes"
>>> nonsense? (And "shadow byte legend" which is meta-nonsense?) I want the
>>> stack
>>> traces, not your internal metadata showing how proud you are of your
>>> implementation details. Grrr. Also, if the _first_ stack trace showing
>>> where the
>>> access _happened_ was actually a STACK TRACE rather than just a single
>>> file+line
>>> address, that would be nice. You give me a trace of where it was
>>> allocated from
>>> but not where the access you're objecting to occurred? Funky priorities,
>>> that...
>>>
>>> Hmmm, the problem doesn't look like it's in wildcard_path(), it seems
>>> like
>>> collect_wildcards() is filling out the deck[] wrong. (Think of
>>> collect_wildcards() as a bit like regcomp() and wildcard_path() as
>>> slightly
>>> regexec, but not really. When the eleventh doctor says "think of a
>>> banana" and
>>> then goes that's a rubbish analogy, forget the banana... yeah.)
>>>
>>> Sigh, adding a test for this sucks because bash defaults to extglob
>>> being off
>>> for -c (where in the hideous nest of rc files it parses on bringup does
>>> that get
>>> switched on, or is this one of those "defaults differ for different
>>> contexts"
>>> things bash loves to do...) And the extra-creaky bit is:
>>>
>>>   $ bash -c 'shopt -s extglob; echo +()'
>>>   bash: -c: line 0: syntax error near unexpected token `('
>>>   bash: -c: line 0: `shopt -s extglob; echo +()'
>>>   $ bash -c $'shopt -s extglob\necho +()'
>>>   +()
>>>
>>> Because the entire line is parsed before any of the commands in it are
>>> run!
>>> Which is #*%(#&%& _NOT_ the case with "for i in a b c; do echo $i; done"
>>> but...
>>> ARGH. Not emailing chet. Not emailing chet.
>>>
>>> Ahem. Not holding up the release for more work on pending either, lemme
>>> get back
>>> to this...
>>>
>>> (And yes, I should probably redo the temporary variable names on the
>>> second pass
>>> of wildcard plumbing. I have a tendency to put random word association
>>> names
>>> into things during development, and then people complain and I remove the
>>> references later. Calling a group wildcards a "deck" is straining it
>>> enough, but
>>> when I've got a second one calling it "ant" is probably unintelligible
>>> outside
>>> the UK. Nope, never actually been there...)
>>>
>>> > $ toybox sh -c '<<0;0'
>>>
>>> I accept that it parsed wrong, but what does... ok, that's start a HERE
>>> document
>>> terminated by the line "0" and then queue up running the command '0'
>>> afterwards,
>>> and then it runs out of input and complains about an unterminated HERE
>>> document
>>> without having proceeded to run the queued 0.
>>>
>>>   $ <<0;potato
>>>   > 0
>>>   bash: potato: command not found
>>>
>>> Right, test for that is just:
>>> shxpect 'queued work after HERE' I$'<<0;echo hello\n' E"> " I$'0\n'
>>> O$'hello\n'
>>>
>>> And yes bash passes it for "TEST_HOST=1 make test_sh".
>>>
>>> Ahem, test added, lemme come back to actually _fixing_ this. Trying to
>>> cut a
>>> release...
>>>
>>> > $ toybox sh -c '{$,}'
>>>
>>> That's actually the same test as trailing $ above, already fixed. (I can
>>> add a
>>> specific test for it, but the actual bug was trailing $ because {$,}
>>> expands to
>>> one argument that's just "$" and then the trailing , drops out because
>>> "" is
>>> ignored in certain circumstances. Interesting corner case actually, you
>>> can
>>> bring it BACK by appending it to an empty string, ala:
>>>
>>>   $ bash -c 'for i in ""{$,}; do echo ="$i"=; done'
>>>   =$=
>>>   ==
>>>   $ ./sh -c 'for i in ""{$,}; do echo ="$i"=; done'
>>>   =$=
>>>   ==
>>>
>>> And yes, mine is getting that right. And I _think_ I already have a test
>>> for it.
>>> Eh, add another anyway just to be sure...
>>>
>>> > floating-point-exception:
>>> > $ toybox sh -c '((0%0))'
>>>
>>> (I actually did this one first.)
>>>
>>> And /= 0. Added two checks and four tests to sh.test. (Catching and
>>> handling the
>>> signal without leaks is unnecessarily awkward. I'd need a siglongjmp()
>>> stack
>>> mechanism, and would prefer the plumbing just not _cause_ those...)
>>>
>>> > Also found some ASAN failures on the vi command.
>>> >
>>> > heap-buffer-overflow:
>>> > $ echo p > input; toybox vi -s input ascii.txt
>>> > stack-buffer-overflow:
>>> > $ echo s000000000000000 > input; toybox vi -s input ascii.txt
>>>
>>> Understood, but I haven't even _started_ review/cleanup of that one yet.
>>>
>>> Moving targets tend to get bumped down the todo list, and even if I _was_
>>> focusing on something but it moved out from under me I may not get back
>>> to it
>>> for _years_. Happend more than once on dd.c, and I should cycle back to
>>> man.c.
>>> Both are low hanging fruit at this point. I'm waiting to see if anything
>>> in the
>>> entire Linux From Scratch build under than the kernel (which I have a
>>> patch for)
>>> actually _uses_ bc, since anybody born after 1980 is either going to use
>>> $((math) or just python -c 'print 37/4.2' . Not that I want to
>>> _encourage_ that.
>>>
>>> > -Eric
>>>
>>> Rob
>>>
>>> P.S. Remind me to let your original email through moderation when I get
>>> home...
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240524/b2e1e739/attachment-0001.htm>