From: Thomas Rast <trast@inf.ethz.ch>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
Thomas Rast <trast@student.ethz.ch>
Subject: Re: [PATCH] unpack_entry: invalidate newly added cache entry in case of error
Date: Tue, 30 Apr 2013 14:53:06 +0200 [thread overview]
Message-ID: <87d2tcw571.fsf@linux-k42r.v.cablecom.net> (raw)
In-Reply-To: <CACsJy8Bi6UpfA-0BCFY6H=BAKMmWYgwbf-94yJXEn5Zi4gwPCA@mail.gmail.com> (Duy Nguyen's message of "Tue, 30 Apr 2013 17:25:05 +0700")
Duy Nguyen <pclouds@gmail.com> writes:
> Apply this patch on top of master (no need to apply full series) and run t5303
>
> http://article.gmane.org/gmane.comp.version-control.git/222895
[...]
> OK since you know this code much better than me, I withdraw my patch
> (consider it a bug report) and let you work on a proper fix. I see you
> already have the commit message ready :) Happy to test it for you if
> the above instruction is still not reproducible for you.
Ok. So I really think just dropping the free() is the way to go. Can
you test this? Your series didn't apply cleanly on anything I had
locally, and 'am -3' doesn't work. A simpler reproducer, and using
valgrind to detect the use-after-free, didn't get me anywhere either.
-- >8 --
Subject: [PATCH] unpack_entry: avoid freeing objects in base cache
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
In the !delta_data error path of unpack_entry(), we run free(base).
This became a window for use-after-free() in abe601b (sha1_file:
remove recursion in unpack_entry, 2013-03-27), as follows:
Before abe601b, we got the 'base' from cache_or_unpack_entry(..., 0);
keep_cache=0 tells it to also remove that entry. So the 'base' is at
this point not cached, and freeing it in the error path is the right
thing.
After abe601b, the structure changed: we use a three-phase approach
where phase 1 finds the innermost base or a base that is already in
the cache. In phase 3 we therefore know that all bases we unpack are
not part of the delta cache yet. (Observe that we pop from the cache
in phase 1, so this is also true for the very first base.) So we make
no further attempts to look up the bases in the cache, and just call
add_delta_base_cache() on every base object we have assembled.
But the !delta_data error path remained unchanged, and now calls
free() on a base that has already been entered in the cache. This
means that there is a use-after-free if we later use the same base
again.
So remove that free().
Reported-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
---
sha1_file.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index 64228a2..67e815b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2128,7 +2128,6 @@ void *unpack_entry(struct packed_git *p, off_t obj_offset,
error("failed to unpack compressed delta "
"at offset %"PRIuMAX" from %s",
(uintmax_t)curpos, p->pack_name);
- free(base);
data = NULL;
continue;
}
--
1.8.3.rc0.333.gdb39496
next prev parent reply other threads:[~2013-04-30 12:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-30 2:29 [PATCH] unpack_entry: invalidate newly added cache entry in case of error Nguyễn Thái Ngọc Duy
2013-04-30 8:27 ` Thomas Rast
2013-04-30 10:25 ` Duy Nguyen
2013-04-30 12:53 ` Thomas Rast [this message]
2013-04-30 13:01 ` Duy Nguyen
2013-04-30 22:39 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d2tcw571.fsf@linux-k42r.v.cablecom.net \
--to=trast@inf.ethz.ch \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.