Re: SHA-1 collision in repository?

On Mar 5, 2018, at 10:54 PM, Myria <myriachan_at_gmail.com> 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.
Received on 2018-03-07 18:02:39 CET