This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Justin N. Ferguson <jf at ownco dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |WONTFIX

--- Comment #7 from Justin N. Ferguson <jf at ownco dot net> ---
(In reply to Andreas Schwab from comment #6)
> There is nothing wrong with that reference.  Please read the comments in
> malloc.c about how the allocator manages its meta data.

Okay. This isn't relevant. There are code paths in realloc() that can trigger
this bug, but even if there were not, it has no bearing on the code in
nsswitch.c, which is where the bug in question is.

Please try to focus on the matter at hand, which is the bug in nsswitch.c, not
malloc.c.

800 while (*currentp != NULL)
801 {
802 if (strcmp ((*currentp)->name, name) == 0)
803 return *currentp;
804 currentp = &(*currentp)->next;
805 }

This code, in nsswitch.c, not malloc.c, increments the currentp ** incorrectly
at line 804. This causes it to point to incorrectly into heap metadata, which
may or may not be set to NULL, depending on the state of the heap-- which in
some instances, particularly edge cases where blocks are being resized and
memory is split from the top chunk IIRC, and the prior block has been
deallocated but not consolidated-- im hesitant to get overly into the semantics
of the heap, because its not relevant-- what is relevant is the code I actually
filed the bug against, which I've copy/pasted again above.

The net result is that you end up calling strcmp() on heap metadata,
specifically (mchunkptr)(x)->prev_size, which is NEVER VALID for you to be
doing, It just works because most of the time, the heap is in a state wherein
(mchunkptr)(x)->prev_size = 0 which == ((void*)0) or NULL.

The bug itself seems benign, and it probably is, but given that its in NSS
(which is not malloc.c), you probably shouldn't take the chance given that
there are any number of unexpected security related issues and environments
that could potentially encounter it.

to reiterate:
x = malloc(y);
x -= 0x10;
strcmp(x, "this is always invalid, period. it doesnt matter what the value of
prev_size is or is not.");

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]