This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING][PATCH][BZ #15073] Fix race in free.
- From: Nate Gallaher <nate at jaybridge dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: Maxim Kuvyrkov <maxim at kugelworks dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 19 Dec 2013 19:59:02 -0500
- Subject: Re: [PING][PATCH][BZ #15073] Fix race in free.
- Authentication-results: sourceware.org; auth=none
- References: <20131210194349 dot GA19644 at domone dot podge> <20131218102757 dot GC6559 at domone dot podge> <9F3FB1EC-C46C-48AC-B77D-71C24424C312 at kugelworks dot com> <CAGFkMStazgdLFfJ5vj7iPc4va7tvAyUCZ7wk8qaLESq-9FBMOw at mail dot gmail dot com> <20131220004620 dot GA29800 at domone dot podge>
Aha. Thank you for clearing that up for me.
On Thu, Dec 19, 2013 at 7:46 PM, OndÅej BÃlka <neleai@seznam.cz> wrote:
> On Thu, Dec 19, 2013 at 07:35:25PM -0500, Nate Gallaher wrote:
>> I am not sure that is a complete solution. I believe that any fastbin
>> content dereference is a potential race point.
>>
>> For example, in _int_malloc:
>> 3268 mfastbinptr* fb = &fastbin (av, idx);
>> 3269 mchunkptr pp = *fb;
>> 3270 do
>> 3271 {
>> 3272 victim = pp;
>> 3273 if (victim == NULL)
>> 3274 break;
>> 3275 }
>> 3276 while ((pp = catomic_compare_and_exchange_val_acq (fb,
>> victim->fd, victim))
>> 3277 != victim);
>>
>> If we assume that there are entries in the fastbin (so pp is non-NULL),
>> and the following happens:
>>
>> Thread #1:
>> * Executes lines 3268 through 3274. pp and victim are non-NULL.
>> Context swap to Thread #2:
>> * Executes code that frees enough memory into the fastbin to trigger the
>> bin consolidation.
>> * Bin consolidation frees the page that pp and victim pointed into using
>> systrim(). This page is returned to the system.
>> Context swap to Thread #1:
>> * In setting up for the compare and swap on line 3276, we dereference
>> victim to get victim->fd. Since victim points to memory that was released
>> to the system, we get a segfault.
>> Is my understanding correct?
>>
> No, malloc is protected by lock (arena_lock/arena_get macros from __libc_malloc/memalign).
>
> Yes, its ineffective which I try to solve by per thread-cache where no
> locking on fast path is necessary.