[uClibc 0005784]: ref counting can wrap in libdl.so

bugs at busybox.net bugs at busybox.net
Thu Oct 30 08:15:24 UTC 2008


A NOTE has been added to this issue. 
====================================================================== 
http://busybox.net/bugs/view.php?id=5784 
====================================================================== 
Reported By:                estesp
Assigned To:                uClibc
====================================================================== 
Project:                    uClibc
Issue ID:                   5784
Category:                   Shared Library Support
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             10-28-2008 10:29 PDT
Last Modified:              10-30-2008 01:15 PDT
====================================================================== 
Summary:                    ref counting can wrap in libdl.so
Description: 
Recently while investigating a problem with pam authentication+uClibc, my
investigation led me to the point where I realized that the dlopen() and
dlclose() management of ref. counting is not balanced, which leads to the
heaviest "DL_NEEDED" libraries basically getting incremented to the point
of overflowing "unsigned short usage_count".  This leads to a nasty
situation where
libc.so is munmapped (because usage_count == 0), and the next call to a
C runtime function traps, of course.

The exact point of trap is in ldso/libdl/libdl.c around line 533:

529      _dl_munmap((void*)tpnt->loadaddr, end); 
530      /* Free elements in RTLD_LOCAL scope list */
531      for (runp = tpnt->rtld_local; runp; runp = tmp) {
532         tmp = runp->next;
533         free(runp);
534      }

When the wrap happens, you will find this code executed where tpnt is
pointing at libc.so--therefore the dl_munmap @ 529 will actually unmap the
code segment of libc.so.   When the free() at line 533 is executed, it will
segfault, given the offset of the function free() (which was in libc.so's
code segment) is now unmapped/inaccessible memory to this process.

====================================================================== 

---------------------------------------------------------------------- 
 bernhardf - 10-30-08 01:15  
---------------------------------------------------------------------- 
I don't have any of those libraries and i cannot reproduce it on trunk with
gmp/mpfr/gcc_s/bz2, can you describe what a lib must look like to trip into
this?
Perhaps you can provide a couple of dummy libs that fulfill the
constraints to reproduce it? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-28-08 10:29  estesp         New Issue                                    
10-28-08 10:29  estesp         Status                   new => assigned     
10-28-08 10:29  estesp         Assigned To               => uClibc          
10-28-08 10:29  estesp         File Added: stress-dlopen.c                    
10-30-08 01:15  bernhardf      Note Added: 0014584                          
======================================================================




More information about the uClibc-cvs mailing list