[PATCH 1/1] ui-log: fix data corruption

[PATCH 1/1] ui-log: fix data corruption

[list]

From: Christian Hesse <mail at eworm.de>

This data is allocated in a bigger context. So we should not free it
here to prevent data corruption.

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 ui-log.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/ui-log.c b/ui-log.c
index a31ff7c..cba91af 100644
--- a/ui-log.c
+++ b/ui-log.c
@@ -484,9 +484,6 @@ void cgit_print_log(const char *tip, int ofs, int cnt, char *grep, char *pattern
 	for (i = 0; i < ofs && (commit = get_revision(&rev)) != NULL; /* nop */) {
 		if (show_commit(commit, &rev))
 			i++;
-		free_commit_buffer(commit);
-		free_commit_list(commit->parents);
-		commit->parents = NULL;
 	}
 
 	for (i = 0; i < cnt && (commit = get_revision(&rev)) != NULL; /* nop */) {
@@ -506,9 +503,6 @@ void cgit_print_log(const char *tip, int ofs, int cnt, char *grep, char *pattern
 			i++;
 			print_commit(commit, &rev);
 		}
-		free_commit_buffer(commit);
-		free_commit_list(commit->parents);
-		commit->parents = NULL;
 	}
 	if (pager) {
 		html("</table><ul class='pager'>");
-- 
2.10.0

[PATCH 1/1] ui-log: fix data corruption

[Jason]

Does this ever get freed, though?

[PATCH 1/1] ui-log: fix data corruption

[list]

"Jason A. Donenfeld" <Jason at zx2c4.com> on Fri, 2016/10/07 21:43:
> Does this ever get freed, though?

I ran cgit in valgrind with this patch applied. No changes in what is lost -
so looks like this is freed later on.

BTW, we have some more places where get_revision() is called. Sometimes we
free the result (ui-atom, ui-log, ui-stats), sometimes we do not (ui-log,
ui-patch).
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20161007/d00a6918/attachment.asc>

[PATCH 1/1] ui-log: fix data corruption

[list]

Christian Hesse <list at eworm.de> on Fri, 2016/10/07 23:21:
> "Jason A. Donenfeld" <Jason at zx2c4.com> on Fri, 2016/10/07 21:43:
> > Does this ever get freed, though?  
> 
> I ran cgit in valgrind with this patch applied. No changes in what is lost -
> so looks like this is freed later on.

Another thought on this... The issue reported by Sylvain Rabot
shows that get_revision() can not get the same commit again. This is an
indication we do free something we should not touch, no?
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20161007/559985fa/attachment-0001.asc>

[PATCH 1/1] ui-log: fix data corruption

[john]

On Fri, Oct 07, 2016 at 11:21:23PM +0200, Christian Hesse wrote:
> "Jason A. Donenfeld" <Jason at zx2c4.com> on Fri, 2016/10/07 21:43:
> > Does this ever get freed, though?
> 
> I ran cgit in valgrind with this patch applied. No changes in what is lost -
> so looks like this is freed later on.

It isn't lost because there's a global reference to it via the commit
cache, but valgrind's "still reachable" statistic definitely grows as a
result of this patch.

I don't think this is the cause of the underlying problem Sylvain
reported.  That's more likely to be the use of
get_cached_commit_buffer() in cgit_parse_commit().  Shouldn't that be
get_commit_buffer(), which uses the cached buffer if it's available?
Otherwise we must call libgit's parse_commit() before calling
cgit_parse_commit(), which all seems a bit fragile.

[PATCH 1/1] ui-log: fix data corruption

[list]

John Keeping <john at keeping.me.uk> on Sun, 2016/10/09 12:26:
> On Fri, Oct 07, 2016 at 11:21:23PM +0200, Christian Hesse wrote:
> > "Jason A. Donenfeld" <Jason at zx2c4.com> on Fri, 2016/10/07 21:43:  
> > > Does this ever get freed, though?  
> > 
> > I ran cgit in valgrind with this patch applied. No changes in what is
> > lost - so looks like this is freed later on.  
> 
> It isn't lost because there's a global reference to it via the commit
> cache, but valgrind's "still reachable" statistic definitely grows as a
> result of this patch.

Ups, missed that.

> I don't think this is the cause of the underlying problem Sylvain
> reported.  That's more likely to be the use of
> get_cached_commit_buffer() in cgit_parse_commit().  Shouldn't that be
> get_commit_buffer(), which uses the cached buffer if it's available?

I have to admit that I am not very familiar with the caching system. :-p

Just replacing that function has the desired effect, though. Calling
cgit_print_branches() after cgit_print_log() works without crash.
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/cgit/attachments/20161010/2c5a1414/attachment.asc>

[PATCH 1/1] ui-log: fix data corruption

[Jason]

So what's the verdict here? Do we have a double free or not?

[PATCH 1/1] ui-log: fix data corruption

[john]

On Wed, Oct 12, 2016 at 01:23:45PM +0200, Jason A. Donenfeld wrote:
> So what's the verdict here? Do we have a double free or not?

The current code is fine, providing we don't re-order it.

The issue is that we free commit blobs while walking the log, so any
attempt to use them after that without reloading the data goes through a
null pointer.

We should possibly change cgit_parse_commit() to use get_commit_buffer()
rather than get_cached_commit_buffer(), which improves the usability of
that function but hides potential inefficiency if we free the buffer and
end up reloading it.

The use of get_cached_commit_buffer() dates from an update in git.git
which moved the buffer pointer out of struct commit, previously we just
accessed commit->buffer here and relied on the buffer having been loaded
previously.