From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14033 invoked by alias); 8 Mar 2012 16:54:53 -0000 Received: (qmail 14020 invoked by uid 22791); 8 Mar 2012 16:54:50 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_CB X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Mar 2012 16:54:37 +0000 From: "law at redhat dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug dynamic-link/13823] New: Bogus LD_AUDIT can cause target binary to segfault Date: Thu, 08 Mar 2012 16:54:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00140.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13823 Bug #: 13823 Summary: Bogus LD_AUDIT can cause target binary to segfault Product: glibc Version: 2.15 Status: NEW Severity: normal Priority: P2 Component: dynamic-link AssignedTo: unassigned@sourceware.org ReportedBy: law@redhat.com Classification: Unclassified Specifying an invalid LD_AUDIT file can cause the target application to segfault. First, you want the target program you're using to do something like setlocale right after it starts. /bin/true and /bin/false are good for this purpose. Second, prelinking is necessary; I don't know why yet, but it was definitely necessary to run a prelink -a after updating ld.so to trigger the behaviour. Third, the auditing bits must be bogus, preferably a non-existent file. So, something like LD_AUDIT=/blah /bin/true Where /blah does not exist turns out to be a good reproducer. >>From what I've been able to put together, when LD_AUDIT is specified we call init_tls earlier than normal: /* If we have auditing DSOs to load, do it now. */ if (__builtin_expect (audit_list != NULL, 0)) { /* Iterate over all entries in the list. The order is important. */ struct audit_ifaces *last_audit = NULL; struct audit_list *al = audit_list->next; /* Since we start using the auditing DSOs right away we need to initialize the data structures now. */ tcbp = init_tls (); ... } ... /* Load all the libraries specified by DT_NEEDED entries. If LD_PRELOAD specified some libraries to load, these are inserted before the actual dependencies in the executable's searchlist for symbol resolution. */ HP_TIMING_NOW (start); _dl_map_object_deps (main_map, preloads, npreloads, mode == trace, 0); HP_TIMING_NOW (stop); HP_TIMING_DIFF (diff, start, stop); HP_TIMING_ACCUM_NT (load_time, diff); /* We do not initialize any of the TLS functionality unless any of the initial modules uses TLS. This makes dynamic loading of modules with TLS impossible, but to support it requires either eagerly doing setup now or lazily doing it later. Doing it now makes us incompatible with an old kernel that can't perform TLS_INIT_TP, even if no TLS is ever used. Trying to do it lazily is too hairy to try when there could be multiple threads (from a non-TLS-using libpthread). */ bool was_tls_init_tp_called = tls_init_tp_called; if (tcbp == NULL) tcbp = init_tls (); At the earlier init_tls call we haven't seen a DSO with TLS bits. As a result init_tls & eventually dl_allocate_tls_init have nothing interesting to do. The result being the TLS bits in libc.so.6 aren't initialized and all hell breaks loose in the locale bits as the thread local variables aren't properly initialized. Ideally if the auditing module is bogus we should just ignore it and the application should run normally. Segfaulting is, umm, bad. I pondered delaying the first init_tls call until we know the auditing module is loadable, but I'm concerned that's simply too late. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.