Bug 3318 - Overriding free which clobbers data and calls pthread_getspecific can get bad value (linuxthreads)
Summary: Overriding free which clobbers data and calls pthread_getspecific can get bad...
Alias: None
Product: glibc
Classification: Unclassified
Component: linuxthreads (show other bugs)
Version: 2.3.6
: P2 normal
Target Milestone: ---
Assignee: drow@false.org
Depends on:
Reported: 2006-10-07 01:52 UTC by Ian Lance Taylor
Modified: 2016-08-22 13:44 UTC (History)
1 user (show)

See Also:
Last reconfirmed:
fweimer: security-

Test case (730 bytes, text/plain)
2006-10-07 01:56 UTC, Ian Lance Taylor

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Lance Taylor 2006-10-07 01:52:33 UTC
This is the linuxthreads version of bugzilla PR 3317, which I reported for NPTL.

If I override the libc free() function, and change that function to clobber some
bytes of the data, and then call pthread_getspecific from that function,
pthread_getspecific can return bad data.  This is because
__pthread_destroy_specifics frees memory before clearing the pointer to it. 
This happens around line 200:

    if (THREAD_GETMEM_NC(self, p_specific[i]) != NULL) {
      free(THREAD_GETMEM_NC(self, p_specific[i]));
      THREAD_SETMEM_NC(self, p_specific[i], NULL);

This should be rewritten to call THREAD_GETMEM_NC, then THREAD_SETMEM_NC, then free.

I will attach a test case which shows the problem on i686-pc-linux-gnu using
Fedora Core 4 with glibc-2.3.6-3 when setting the environment variable
Comment 1 Ian Lance Taylor 2006-10-07 01:56:10 UTC
Created attachment 1357 [details]
Test case

This test case crashes for me on i686-pc-linux-gnu running Fedora Core 4 with
glibc-2.3.6-3 when I set the environment variable LD_ASSUME_KERNEL to 2.4.19. 
In the __libc_free routine, pthread_getspecific returns garbage.

This isn't the simplest possible test case--it's a modification of the NPTL
test case.  The call to abort winds up hanging as the pthread code waits for a
lock, so I put in an alarm to get the program to actually exit.  The hang is
probably due to the bug I reported in bugzilla PR 2948, which has been fixed in
the mainline sources.
Comment 2 Daniel Jacobowitz 2006-10-31 15:31:23 UTC
Sorry, but I don't think there's any point in diverging from NPTL on this point;
LinuxThreads is strictly end of life now.  It's reasonably easy to work around
this bug and in fact I'm not sure how you ever encountered it; the sequence
number is first, and if you clobber that, pthread_getspecific will return NULL.
Comment 3 Daniel Jacobowitz 2006-10-31 21:49:46 UTC
After talking to Ian...
Comment 4 Daniel Jacobowitz 2006-10-31 21:50:06 UTC
... I checked in a fix for this, in case LinuxThreads ever builds again.