[Bug libc/18292] Invalid pointer dereference in nsswitch.c:nss_new_service()

["jf at ownco dot net" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #11 from Justin N. Ferguson <jf at ownco dot net> ---
> I assume that this is about the prev_size member of the following chunk. 
> Have you increased the chunk size accordingly (by the size of a pointer)? 
> If not, your malloc invalid because prev_size is only available if the
> preceding chunk is free, as explained in comment #2.

Well, we are debating semantics here in terms of where prev_size exists, its
quite obviously not being stored in the prior block in my reading as discerned
that an allocation will be at least 16-bytes/32-bytes on a 64-bit platform; The
pointer returned to the user is 16-bytes past the start of the allocation, with
the prev_size and size members being the header and the 16 remaining bytes
being utilized after free for forward and back pointers (assuming its not a
fastbin chunk).

So, the prev_size member is always available in the header of the allocation,
it's just often not initialized or similar. Furthermore, it would seem
self-evident to me that this is obviously not the case when we consider the top
chunk; but again, its semantics. It appears to be a non-issue because the field
is almost always written to before its read, but I am in the process of trying
to confirm all edge cases of this for myself.

A block that is mmap'd uses the prev_size member to store metadata when it is
allocated, because mmap'd chunks do not have a previous chunk next to them in
terms of the logic of the allocator, however this is not entirely true because
you can do subsequent allocations and force two mmap'd chunks to be next to
each other.

However, the issue itself appears when (only when?) we split a new block off of
the top block, where the arithmetic is treated as 16-bytes as opposed to the
more typical 32-bytes, leaving the next allocation from top overlapping with
the last-- which doesn't *appear* to be usable in terms of mmap'd memory, but
I'm still doofing around trying to make sure there is no clear way to handle
this.

> valgrind also does not show any out-of-bounds references, and it is 
> usually very precise for such issues.

Yeah well there are a lot of things automated tools don't detect, and they
often revolve around sections of code that cross multiple boundaries or where a
particular issue depends on how an OS handles things (id est mmap placements),
or other problem specific semantics that do not appear in many many use cases.

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