Bug 19810 - dlopen with both RTLD_NOLOAD and RTLD_NODELETE causes a segmentation fault
Summary: dlopen with both RTLD_NOLOAD and RTLD_NODELETE causes a segmentation fault
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: 2.23
: P2 normal
Target Milestone: 2.25
Assignee: Not yet assigned to anyone
URL: http://bugs.debian.org/817900
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-11 18:22 UTC by Aurelien Jarno
Modified: 2016-09-05 20:44 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aurelien Jarno 2016-03-11 18:22:28 UTC
Since glibc 2.22, dlopen(LIBM_SO, RTLD_LAZY | RTLD_NOLOAD | RTLD_NODELETE) triggers a segmentation fault instead of returning a NULL pointer.

This is caused by the following commit:

commit b632bdd3f7c0ba0c79f23f5e4404eebb87ebdaa8
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Thu Jul 16 08:53:28 2015 +0530

    Set NODELETE flag when opening already open objects with RTLD_NODELETE
    
    The DF_1_NODELETE flag is set too late when opening a DSO, due to
    which, if a DSO is already open, subsequently opening it with
    RTLD_NODELETE fails to set the DF_1_NODELETE flag.  This patch fixes
    this by setting the flag immediately after bumping the opencount.
    
    Verified on x86_64.
    
        [BZ #18676]
        * elf/tst-nodelete-opened.c: New test case.
        * elf/tst-nodelete-opened-lib.c: New test case module.
        * elf/Makefile (tests, modules-names): Use them.
        * elf/dl-open.c (dl_open_worker): Set DF_1_NODELETE flag
        early.

The setting of the NODELETE has been moved a tiny bit too early. A patch will follow on the mailing list.
Comment 1 cvs-commit@gcc.gnu.org 2016-09-03 20:03:30 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  ead3cea7d8948113fe205243acbddbda609de5c9 (commit)
      from  6b75ba1388bff6a81bad410d7318d385a043b3cb (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ead3cea7d8948113fe205243acbddbda609de5c9

commit ead3cea7d8948113fe205243acbddbda609de5c9
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Sat Sep 3 20:25:59 2016 +0200

    Set NODELETE flag after checking for NULL pointer
    
    The commit b632bdd3 moved the setting of the DF_1_NODELETE flag earlier
    in the dl_open_worker function. However when calling dlopen with both
    RTLD_NODELETE and RTLD_NOLOAD, the pointer returned by _dl_map_object is
    NULL. This condition is checked just after setting the flag, while it
    should be done before. Fix that.
    
    Changelog:
    	[BZ #19810]
    	* elf/dl-open.c (dl_open_worker): Set DF_1_NODELETE flag later.
    	* elf/tst-noload.c: New test case.
    	* elf/Makefile (tests): Add tst-noload.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                        |    7 +++
 elf/Makefile                                     |    3 +-
 elf/dl-open.c                                    |   12 +++---
 stdio-common/tst-fmemopen4.c => elf/tst-noload.c |   52 +++++++++++----------
 4 files changed, 42 insertions(+), 32 deletions(-)
 copy stdio-common/tst-fmemopen4.c => elf/tst-noload.c (50%)
Comment 2 Aurelien Jarno 2016-09-03 20:28:16 UTC
Fixed in commit ead3cea7d8948113fe205243acbddbda609de5c9
Comment 3 joseph@codesourcery.com 2016-09-05 15:31:45 UTC
Please set the target milestone when marking a bug as fixed.
Comment 4 Aurelien Jarno 2016-09-05 17:52:48 UTC
(In reply to joseph@codesourcery.com from comment #3)
> Please set the target milestone when marking a bug as fixed.

Sorry, I didn't know about that, I will try to do that better. Also I don't know bugzilla very well, therefore I would appreciate some hint about how to to that. I am not able to edit or select the value, contrary to other fields.
Comment 5 joseph@codesourcery.com 2016-09-05 20:12:47 UTC
On Mon, 5 Sep 2016, aurelien at aurel32 dot net wrote:

> Sorry, I didn't know about that, I will try to do that better. Also I don't
> know bugzilla very well, therefore I would appreciate some hint about how to to
> that. I am not able to edit or select the value, contrary to other fields.

I've added you to the editbugs group.

The target milestone field is used to produce the list of fixed bugs in 
the NEWS file, so should be set to the first mainline release with the 
fix.  See: https://sourceware.org/glibc/wiki/Bugzilla%20Procedures
Comment 6 Aurelien Jarno 2016-09-05 20:44:47 UTC
(In reply to joseph@codesourcery.com from comment #5)
> I've added you to the editbugs group.
> 
> The target milestone field is used to produce the list of fixed bugs in 
> the NEWS file, so should be set to the first mainline release with the 
> fix.  See: https://sourceware.org/glibc/wiki/Bugzilla%20Procedures

Thanks, I have just done the change.