Michael Haggerty <mhag...@alum.mit.edu> writes: > If do_one_ref() is called recursively, then the inner call should not > permanently overwrite the value stored in current_ref by the outer > call. Aside from the tiny optimization loss, peel_ref() expects the > value of current_ref not to change across a call to peel_entry(). But > in the presence of replace references that assumption could be > violated by a recursive call to do_one_ref: > > do_for_each_entry() > do_one_ref() > builtin/describe.c:get_name() > peel_ref() > peel_entry() > peel_object () > deref_tag_noverify() > parse_object() > lookup_replace_object() > do_lookup_replace_object() > prepare_replace_object() > do_for_each_ref() > do_for_each_entry() > do_for_each_entry_in_dir() > do_one_ref() > > The inner call to do_one_ref() was unconditionally setting current_ref > to NULL when it was done, causing peel_ref() to perform an invalid > memory access. > > So change do_one_ref() to save the old value of current_ref before > overwriting it, and restore the old value afterward rather than > setting it to NULL. > > Reported by: Mantas Mikulėnas <graw...@gmail.com> > > Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu> > ---
Thanks. s/Reported by:/Reported-by:/ and lose the extra blank line after it? I wonder if we can have an easy reproduction recipe in our tests. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
