Bugs in fossil --args .
(1) By ET. on 2019-01-18 18:24:56 [link] [source]
Hi all,
Here are some more random bugs I discovered in fossil
1. Infinite loop in fossil --args .
Passing a directory to fossil --args causes blob_read_from_channel
to fread the directory.
809 while( !feof(in) ){
810 n = fread(zBuf, 1, sizeof(zBuf), in);
2. head -c 4M < /dev/urandom | fossil --args -
realloc(): invalid next size
Aborted (core dumped)
head -c 5M < /dev/urandom | fossil --args -
Segmentation fault (core dumped)
(2) By sean (jungleboogie) on 2019-01-22 00:28:41 in reply to 1 [link] [source]
If you didn't see the commit from today, try again.
(3) By ET. on 2019-01-22 06:06:07 in reply to 2 [link] [source]
Can confirm fixed. Thanks
(4) By ET. on 2021-08-05 05:53:51 in reply to 3 [source]
This buffer overflow lives on.
$ echo -ne '\x61\x0a\x61\x00\x0a\x61\x0a\x61\x0a\x61\x0a\x61\x0a' > urandom
$ fossil --args urandom
malloc(): invalid size (unsorted)
Aborted (core dumped)
$ fossil --args - < urandom
fossil: malloc.c:2539: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Aborted (core dumped)
$ valgrind fossil --args urandom
==350016== Memcheck, a memory error detector
==350016== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==350016== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==350016== Command: fossil --args urandom
==350016==
==350016== Invalid write of size 8
==350016== at 0x20AB3B: expand_args_option (in /usr/bin/fossil)
==350016== by 0x20AFD1: fossil_main (in /usr/bin/fossil)
==350016== by 0x1440F8: main (in /usr/bin/fossil)
==350016== Address 0x50a6458 is 0 bytes after a block of size 56 alloc'd
==350016== at 0x483E7C5: malloc (vg_replace_malloc.c:380)
==350016== by 0x2BB245: fossil_malloc (in /usr/bin/fossil)
==350016== by 0x20AA2C: expand_args_option (in /usr/bin/fossil)
==350016== by 0x20AFD1: fossil_main (in /usr/bin/fossil)
==350016== by 0x1440F8: main (in /usr/bin/fossil)
==350016==
fossil: ambiguous command prefix: a
fossil: could be any of: access-log add addremove admin-log alerts all allow-symlinks amend annotate artifact attachment auto-captcha auto-hyperlink auto-shun autosync autosync-tries
fossil: use "help" for more information
==350016==
==350016== HEAP SUMMARY:
==350016== in use at exit: 563 bytes in 11 blocks
==350016== total heap usage: 19 allocs, 8 frees, 6,842 bytes allocated
==350016==
==350016== LEAK SUMMARY:
==350016== definitely lost: 0 bytes in 0 blocks
==350016== indirectly lost: 0 bytes in 0 blocks
==350016== possibly lost: 0 bytes in 0 blocks
==350016== still reachable: 563 bytes in 11 blocks
==350016== suppressed: 0 bytes in 0 blocks
==350016== Rerun with --leak-check=full to see details of leaked memory
==350016==
==350016== For lists of detected and suppressed errors, rerun with: -s
==350016== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
(5) By Stephan Beal (stephan) on 2021-08-05 11:37:33 in reply to 4 [link] [source]
==350016==
==350016== Invalid write of size 8
==350016== at 0x20AB3B: expand_args_option (in /usr/bin/fossil)
==350016== by 0x20AFD1: fossil_main (in /usr/bin/fossil)
==350016== by 0x1440F8: main (in /usr/bin/fossil)
==350016== Address 0x50a6458 is 0 bytes after a block of size 56 alloc'd
==350016== at 0x483E7C5: malloc (vg_replace_malloc.c:380)
==350016== by 0x2BB245: fossil_malloc (in /usr/bin/fossil)
==350016== by 0x20AA2C: expand_args_option (in /usr/bin/fossil)
==350016== by 0x20AFD1: fossil_main (in /usr/bin/fossil)
==350016== by 0x1440F8: main (in /usr/bin/fossil)
This clearly falls, IMO, into the categories of both "garbage in, garbage out" and "well, then don't do that!" but an invalid write is of course unacceptable. i'm looking into this now and will hopefully understand and resolve it soon. A cursory glance doesn't reveal the culprit, other than that the embedded NUL byte in your input file is the trigger.
(6) By Stephan Beal (stephan) on 2021-08-05 12:01:26 in reply to 4 [link] [source]
This buffer overflow lives on.
This is now resolved in trunk. The cause was, in effect, a mismatch between that routine's own line-counting handling (for determining the number of arguments to allocate memory for before actually processing them) and the tokenizer's view of the world. The latter does not treat that embedded NUL byte specially, so effectively ends up counting more lines than we've allocated memory for, leading to the buffer overrun. The trivial patch was to ensure that the offending loop which previously depended only on the tokenizer's view now also ensures that we do not attempt to tokenize past the first NUL byte. i.e. any --args FILE input after the first NUL byte is now ignored.
(7) By ET. on 2021-08-06 05:39:57 in reply to 6 [link] [source]
I can confirm your commit fixes this issue. Thanks.