Bug 338137 – dev-util/ccache-2.4* segfault in util.c:x_realloc()

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Chris Coleman 2010-09-20 11:04:33 UTC]

This bug has long been fixed upstream, but portage still only carries ccache 2.4 which has this crazy realloc function:

void *x_realloc(void *ptr, size_t size)
{
        void *p2;
        if (!ptr) return x_malloc(size);
        p2 = malloc(size);
        if (!p2) {
                fatal("out of memory in x_realloc");
        }
        if (ptr) {
                memcpy(p2, ptr, size);
                free(ptr);
        }
        return p2;
}

I get a segfault every time with `ccache -c`. The problem is the call to memcpy. When x_realloc is used to enlarge a memory block it will read beyond the allocated heap memory in ptr.

The obvious solution is to just use the system realloc.

I came across this bug many months ago. I didn't report it at the time because I saw that it had been fixed upstream and thought that the new releases would soon arrive in portage. Hopefully ccache 3.x will be in portage soon. But while we're all still using 2.4 it really ought to be patched.

Reproducible: Always

Steps to Reproduce:

[Comment 1 Chris Coleman 2010-09-20 11:05:22 UTC]

Created attachment 248108 [details, diff]
fix broken x_realloc

[Comment 2 Chris Coleman 2010-09-20 11:17:10 UTC]

ping robbat2

[Comment 3 SpanKY 2010-09-22 22:39:08 UTC]

i reported this upstream already:
https://bugzilla.samba.org/show_bug.cgi?id=7090

and they've committed a fix for it

[Comment 4 Chris Coleman 2010-09-23 05:02:48 UTC]

(In reply to comment #3)
> i reported this upstream already:
> https://bugzilla.samba.org/show_bug.cgi?id=7090
> 
> and they've committed a fix for it
> 

But it's still in ccache 2.4, and that's the only version of ccache in portage. I think 3.x is due in portage, but 2.4 will continue to be used for a while, especially by stable users. I think this is serious enough to warrant backporting the patch. It breaks a feature on my system (ccache -c).

[Comment 5 SpanKY 2010-09-27 19:04:24 UTC]

the point is to use the fix that went in upstream and not any other random version that someone wrote.

[Comment 6 Chris Coleman 2010-09-27 19:14:18 UTC]

(In reply to comment #5)
> the point is to use the fix that went in upstream and not any other random
> version that someone wrote.
> 

Oh. Fair enough. Here it comes.

[Comment 7 Chris Coleman 2010-09-27 19:14:40 UTC]

Created attachment 248812 [details, diff]
fix broken x_realloc

[Comment 8 Chris Coleman 2010-10-11 22:25:03 UTC]

(In reply to comment #7)
> Created an attachment (id=248812) [details]
> fix broken x_realloc
> 

Please could someone commit an ebuild with this patch. You there. Yes you.

[Comment 9 Chris Coleman 2010-10-11 23:21:39 UTC]

Created attachment 250287 [details]
revised ebuild

[Comment 10 Chris Coleman 2010-10-11 23:21:59 UTC]

Created attachment 250289 [details, diff]
same patch, nicer name

[Comment 11 Chris Coleman 2010-10-20 22:50:06 UTC]

This was reported in 2008 as bug #250309.

[Comment 12 Chris Coleman 2010-10-21 04:19:35 UTC]

This stupid mistake has been in ccache since 2004. Why is it so difficult to get this fixed?

I hate you all.

[Comment 13 SpanKY 2010-10-21 20:18:56 UTC]

go away

[Comment 14 Chris Coleman 2010-10-21 20:28:35 UTC]

(In reply to comment #13)
> go away
> 

My last comment lacked basic politeness. Sorry about that. I don't really hate you all. But is there a reason that this bug is being ignored? Did I do something wrong? Is the patch not acceptable?

[Comment 15 Chris Coleman 2010-10-22 21:30:09 UTC]

Please accept my sincere apologies for my impatience and irateness. I've been under some stress. I won't be pestering you any more about this relatively trivial bug.

[Comment 16 SpanKY 2010-11-19 07:54:22 UTC]

ive added the fix from upstream to 2.4-r9 for Robin