On 29.08.2016 18:57, Daniel Shahaf wrote:
> When the "props:" line in a noderev lists an all-zeroes checksum, FSFS
> segfaults:
>
> [[[
> % cat repro.sh
> #!/bin/sh
> rm -rf r wc
> svnadmin create r
> svn co -q file://`pwd`/r wc
> svn ps -q k v wc
> svn ci -qmm wc
> echo "First dump:"
> svnadmin dump -q r >/dev/null
> perl -pi -e 's/[0-9a-f]{16,}/"0" x length $&/e if /^props:/' r/db/revs/0/1
> echo "Second dump:"
> svnadmin dump -q r >/dev/null
> ]]]
>
> Output:
> [[[
> % ./repro.sh
> First dump:
> Second dump:
> Segmentation fault
> zsh: exit 139 ./repro.sh
> ]]]
>
> This is caused by these two lines in svn_fs_fs__parse_representation():
> .
> 801 SVN_ERR(svn_checksum_parse_hex(&checksum, svn_checksum_md5, str,
> 802 scratch_pool));
> 803 memcpy(rep->md5_digest, checksum->digest, sizeof(rep->md5_digest));
> .
> Line 801 sets CHECKSUM to NULL (as promised by svn_checksum_parse_hex()'s
> docstring), line 803 dereferences it unconditionally.
Fixed trivially in r1759686.
It appears that it might be very hard to get such data into the
repository because we use the same parser function in e.g. the
network layer and the editor drivers. Not sure we all for MD5s etc.
to be missing in all relevant places.
That said, it is at least conceivable that some all-0 SHA1 snug in
in an earlier version (1.5?) as a result of some inconsistent code.
Those occurrences would be dormant and inconsequential pre 1.9
and they should stay that way. Therefore, I proposed r1759686
for backporting.
-- Stefan^2.
Received on 2016-09-08 17:51:52 CEST