subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Hartman <>
Subject Re: SHA-1 collision in repository?
Date Wed, 07 Mar 2018 17:02:26 GMT
On Mar 5, 2018, at 10:54 PM, Myria <> wrote:
> Final email for the night >.<
> What's clobbering the expanded_size is this in build_rep_list:
>  /* The value as stored in the data struct.
>     0 is either for unknown length or actually zero length. */
>  *expanded_size = first_rep->expanded_size;
> first_rep->expanded_size here is zero for the last call to this
> function before the error.  In every other case before the error, the
> two values are equal.
> Then this code executes:
>  if (*expanded_size == 0)
>    if (rep_header->type == svn_fs_fs__rep_plain || first_rep->size != 4)
>      *expanded_size = first_rep->size;
> first_rep->size is 16384, and this is why rb->len becomes 16384,
> leading to the error.
> I don't know what all this code is doing, but that's the proximate
> cause of the failure.
> Melissa

Has it been possible to determine what is setting expanded_size to 0 before that last call?
I wonder if there is specific logic that decides (perhaps incorrectly?) to do that?

Alternatively is it being clobbered by some out-of-bounds access, use-after-free, or another
such issue?

Is it possible in your debugger setup to determine the address of that variable and set a
breakpoint that triggers when that memory is written? (It may be called a watchpoint?)

Which leads me to another thought: if you can set such a breakpoint / watchpoint and it does
not trigger, then this expanded_size might not be the same instance in that final call. Perhaps
a shallow copy of an enclosing structure is made which leaves out the known size and sets
it to 0 for some reason, and that final call is given that (incomplete) copy.

Caveat: I am not familiar with the codebase but these are my thoughts based on adventures
in other code bases.

View raw message