[Bug malloc/20155] New: malloc: Inconsistent chunk size checks

["fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 20155
           Summary: malloc: Inconsistent chunk size checks
           Product: glibc
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
  Target Milestone: ---
             Flags: security-

sysmalloc sets a bunch with size 2 * SIZE_SZ:

          /* The fencepost takes at least MINSIZE bytes, because it might
             become the top chunk again later.  Note that a footer is set
             up, too, although the chunk is marked in use. */
          old_size = (old_size - MINSIZE) & ~MALLOC_ALIGN_MASK;
          set_head (chunk_at_offset (old_top, old_size + 2 * SIZE_SZ), 0 |
PREV_INUSE);
          if (old_size >= MINSIZE)
            {
              set_head (chunk_at_offset (old_top, old_size), (2 * SIZE_SZ) |
PREV_INUSE);
              set_foot (chunk_at_offset (old_top, old_size), (2 * SIZE_SZ));
              set_head (old_top, old_size | PREV_INUSE | NON_MAIN_ARENA);
              _int_free (av, old_top, 1);

(Setting the NON_MAIN_ARENA flag here is rather dubious.)

_int_free checks against 2 * SIZE_SZ:

    if (__builtin_expect (nextchunk->size <= 2 * SIZE_SZ, 0)
        || __builtin_expect (nextsize >= av->system_mem, 0))
      {
        errstr = "free(): invalid next size (normal)";
        goto errout;
      }

This only works because nextchunk->size is actually 2 * SIZE_SZ + 1: the
PREV_INUSE flag is set.

We have a couple of other such comparisons which could also give unexpected
results.  Whether this intended or not is unclear.

It's questionable to patch into the heap chunks smaller than MINSIZE (in the
way sysmalloc does) because it violates heap invariants.

I don't know what to do about this.  Such subtle tricks certainly make changes
to the code more difficult.

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