[PATCH] memalign: Add alignment overflow check (CVE-2026-0861)

Wilco Dijkstra Wilco.Dijkstra@arm.com
Thu Jan 15 12:45:39 GMT 2026


Hi Siddhesh,

> Thanks, that takes away my discomfort of hardcoding 8 bits per byte, but
> I assume you mean the following?
>
>    2 << (__builtin_clzl (1) - __builtin_clzl (alignment - 1))

What is the purpose of the -1? It's redundant (and would cause undefined
behaviour if alignment == 1 - a valid power of 2).

>  From the formula we can conclude that alignment == PTRDIFF_MAX + 1
> should always return NULL and set ENOMEM. Thus the trivial fix is:
>
>    if (bytes > PTRDIFF_MAX || alignment > PTRDIFF_MAX)
>      {
>        __set_errno (ENOMEM);
>        return NULL;
>      }
>
> at the start of _int_memalign. That way we don't do a complex overflow check
> in a different function (and it doesn't go wrong if _int_memalign changes).

> I missed the fact that checked_request2size() could round bytes up.
> Then we do need the two overflow checks, because there's a potential for
> overflow in arena_get (ar_ptr, bytes + alignment + MINSIZE) in
> _mid_memalign too.

That's not ever going to work. There are many places where the size value is
incremented again and where things might overflow for large input values.
We also add top pad in many places assuming nobody sane will set so huge it
could overflow.

So we just need to limit size and alignment to reasonable values. And if we
want to be able to round up the size with top pad or align to a huge page
(like 1GB on a 32-bit system), then we may need to force much lower limits
than PTRDIFF_MAX, including for all these tunables...

Cheers,
Wilco



More information about the Libc-alpha mailing list