Hi,
Unfortunately, no. It was triggered by a proprietary userland application.
And since it is a concurrency problem it can be difficult to create a
reliable test.
I guess one could just hammer malloc() and memalign() with a bunch of pthreads,
and see if the application crashes.
Best regards,
Kjetil Oftedal
On Wed, 25 Sep 2019 at 10:02, Yann Sionneau <ysionneau(a)kalray.eu> wrote:
Hello,
Do you have a small test case that could reproduce the issue that could
be added to uClibc-ng testsuite?
Thanks!
Yann
On 9/25/19 9:59 AM, Kjetil Oftedal wrote:
> The internal heap structures were not protected properly in
> memalign(). If multiple threads were concurrently allocating memory and
> one of them were requesting aligned memory via valloc,memalign or
> posix_memalign the internal heap data structures could be corrupted.
>
> Signed-off-by: Kjetil Oftedal <oftedal(a)gmail.com>
> ---
> libc/stdlib/malloc/memalign.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libc/stdlib/malloc/memalign.c b/libc/stdlib/malloc/memalign.c
> index 74d5dbd..0d3de67 100644
> --- a/libc/stdlib/malloc/memalign.c
> +++ b/libc/stdlib/malloc/memalign.c
> @@ -77,7 +77,9 @@ memalign (size_t alignment, size_t size)
> init_size = addr - tot_addr;
> }
>
> + __heap_lock (&__malloc_heap_lock);
> __heap_free (heap, base, init_size);
> + __heap_unlock (&__malloc_heap_lock);
>
> /* Remember that we've freed the initial part of MEM. */
> base += init_size;
> @@ -85,9 +87,11 @@ memalign (size_t alignment, size_t size)
>
> /* Return the end part of MEM to the heap, unless it's too small. */
> end_addr = addr + size;
> - if (end_addr + MALLOC_REALLOC_MIN_FREE_SIZE < tot_end_addr)
> + if (end_addr + MALLOC_REALLOC_MIN_FREE_SIZE < tot_end_addr) {
> + __heap_lock (&__malloc_heap_lock);
> __heap_free (heap, (void *)end_addr, tot_end_addr - end_addr);
> - else
> + __heap_unlock (&__malloc_heap_lock);
> + } else
> /* We didn't free the end, so include it in the size. */
> end_addr = tot_end_addr;
>