[Bug malloc/33796] New: Integer overflow in _int_memalign leads to heap corruption

[siddhesh at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=33796

            Bug ID: 33796
           Summary: Integer overflow in _int_memalign leads to heap
                    corruption
           Product: glibc
           Version: 2.41
            Status: NEW
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: siddhesh at sourceware dot org
          Reporter: siddhesh at sourceware dot org
  Target Milestone: ---
             Flags: security+

## Summary

Integer overflow in `_int_memalign` when computing `nb + alignment + MINSIZE`
causes allocation of a tiny buffer while writing heap metadata at huge offsets,
resulting in memory corruption.

## Vulnerable Code

```c
// malloc/malloc.c:4701-4746
static void *
_int_memalign (mstate av, size_t alignment, size_t bytes)
{
mchunkptr p, newp;

if (bytes > PTRDIFF_MAX) // Only checks bytes
{
__set_errno (ENOMEM);
return NULL;
}
size_t nb = checked_request2size (bytes);

/* Call malloc with worst case padding to hit alignment. */
void *m = _int_malloc (av, nb + alignment + MINSIZE); // <-- OVERFLOW HERE

if (m == NULL)
return NULL;

p = mem2chunk (m);
...
size_t size = chunksize (p); // Returns tiny size from undersized chunk

if (!PTR_IS_ALIGNED (m, alignment))
{
...
set_head (newp, size | PREV_INUSE | arena_flag); // Writes at wrong offset
set_inuse_bit_at_offset (newp, size); // Heap corruption
...
}
```

When `alignment = 2^63` and `bytes ≈ PTRDIFF_MAX`, the sum wraps to ~0. The
allocator returns a tiny chunk, but the code writes headers based on the
expected huge size.

## Root Cause

Commit `9bf8e29ca13` (2018-12-18, "malloc: make malloc fail with requests
larger than PTRDIFF_MAX") removed the overflow guard that was added in
`8e448310d7` (BZ#22343):

```c
// Removed check:
if (nb > SIZE_MAX - alignment - MINSIZE) { __set_errno(ENOMEM); return 0; }
```

The author assumed capping `bytes` at `PTRDIFF_MAX` was sufficient, but
`alignment` can be up to `2^63`, making the sum still overflow.

## Affected Functions

`posix_memalign`, `aligned_alloc`, `memalign`, `valloc`, `pvalloc`

## Reproduction

```c
#include <stdlib.h>
#include <stdint.h>

int main(void) {
void *p;
posix_memalign(&p, 1ULL << 63, PTRDIFF_MAX - 0x30);
return 0;
}
```

**Result:** SIGSEGV in `_int_memalign` (heap metadata write beyond allocation).
```
0x0000ffff97251eec in _int_memalign (av=av@entry=0xffff97360af0 <main_arena>,
alignment=9223372036854775808, bytes=bytes@entry=9223372036854775759) at
./malloc/malloc.c:4999
#0 0x0000ffff97251eec in _int_memalign (av=av@entry=0xffff97360af0
<main_arena>, alignment=9223372036854775808,
bytes=bytes@entry=9223372036854775759) at ./malloc/malloc.c:4999
#1 0x0000ffff972527bc in _mid_memalign (alignment=<optimized out>,
alignment@entry=9223372036854775808, bytes=bytes@entry=9223372036854775759,
address=<optimized out>) at ./malloc/malloc.c:3557
#2 0x0000ffff9725405c in __posix_memalign (size=9223372036854775759,
alignment=9223372036854775808, memptr=0xffffe817a690) at ./malloc/malloc.c:5686
#3 __posix_memalign (memptr=0xffffe817a690, alignment=9223372036854775808,
size=9223372036854775759) at ./malloc/malloc.c:5670
#4 0x0000aaaad93709ac in main () at memalign_overflow_poc.c:39
```

Reported-by: Igor Morgenstern, Aisle Research

-- 
You are receiving this mail because:
You are on the CC list for the bug.