object-name: avoid use-after-free in get_oid_with_context_1()

When a ":<path>" argument names a relative path, resolve_relative_path()
returns a newly allocated string and "cp" is pointed at it:

	new_path = resolve_relative_path(repo, cp);
	if (!new_path) {
		namelen = namelen - (cp - name);
	} else {
		cp = new_path;
		namelen = strlen(cp);
	}

From there on "cp" and "new_path" name the same allocation. Later the
memory location that "new_path" points to is freed.

	free(new_path);
	if (reject_tree_in_index(repo, only_to_die, ce, stage, prefix, cp))

But here the reject_tree_in_index() passes "cp" to
diagnose_invalid_index_path(), which calls strlen() on it, looks it up
in the index, and formats it into its messages, allocating as it goes.
All of this reads memory that has already been freed.

Collapse the two exits into one to ensure a single free() that happens
after the last use.

Three things have to coincide to reach this:

1. The path has to be relative, or nothing is allocated and "cp"
still points into the argument.

2. The entry found has to be a sparse
directory, which needs a sparse index.

3. The argument has to get past the check in die_verify_filename() that
skips a leading ':' followed by a non-alphanumeric, so ":0:./dir/"
arrives here where ":./dir/" does not.

Add a test to t1092 that covers the combination. It fails under
SANITIZE=address without the change to object-name.c.

This was reported in [1], and the shape used here was suggested in
review [2], but that series was not rerolled and the fix never landed.

[1] https://lore.kernel.org/git/cf6bcdb43e5b4abab464c30a914d64dc8e7a9925.1655336146.git.gitgitgadget@gmail.com/
[2] https://lore.kernel.org/git/xmqqy1xxw7rc.fsf@gitster.g/

Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Original-patch-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Helped-by: Junio C Hamano <gitster@pobox.com>
Suggested-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Shlok Kulshreshtha <diy2903@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

0 files changed, 0 insertions, 0 deletions