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...
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: linuxthreads (show other bugs)
Version: 2.3.6
: P2 normal
Target Milestone: ---
Assignee: drow@false.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-07 01:52 UTC by Ian Lance Taylor
Modified: 2016-08-22 13:44 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-

Attachments
Test case (730 bytes, text/plain)
2006-10-07 01:56 UTC, Ian Lance Taylor 		Details
View All Add an attachment (proposed patch, testcase, etc.)

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
LD_ASSUME_KERNEL to 2.4.19.
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.