Re: [Xenomai-core] Potential heap corruption on thread cleanup

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Hi Gilles,
>>
>> I'm pushing your findings to the list, also as my colleagues showed
>> strong interest - this thing may explain rare corruptions for us as well.
>>
>> I thought a bit about that likely u_mode-related crash in your test case
>> and have the following theory so far: If the xeno_current_mode storage
>> is allocated on the application heap (!HAVE_THREAD, that's also what we
>> are forced to use), it is automatically freed on thread termination in
>> the context of the dying thread. If the thread is already migrated to
>> secondary or if that happens while it is cleaned up (i.e. before calling
>> for exit into the kernel), there is no problem, Xenomai will not touch
>> the mode storage anymore. But if the thread happens to delete the
>> storage "silently", without any migration, the final exit will trigger
>> one further access. And that takes place against an invalid head area at
>> this point.
>>
>> Does this make sense?
> 
> Yes, it is the issue we observed.
> 
>> If that is true, all we need to do is to force a migration before
>> releasing the mode storage. Could you check this?
> 
> No, that does not fly. Calling, for instance, __wrap_pthread_mutex_lock
> in another TSD cleanup function is which could be called after the
> current_mode TSD cleanup is allowed and could trigger a switch to
> primary mode and a write to the u_mode.
> 

Good point. Mmh. Another, but ABI-breaking, way would be to add a
syscall for deregistering the u_mode pointer...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]