GNU bug report logs - #21056
[BUG] Bug with dirname on Ubuntu

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21056 in the body.
You can then email your comments to 21056 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vinh Nguyen <vnguyen <at> opswat.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Cc: Dave Patt <dpatt <at> opswat.com>
Subject: [BUG] Bug with dirname on Ubuntu
Date: Tue, 14 Jul 2015 09:04:44 +0000

[Message part 1 (text/plain, inline)]

Dear Sir/Madam,
I've found a bug with dirname function on Ubuntu 14.04 LTS. The context is:
        Dl_info info;
        if ( dladdr( ( const void* )function_to_get_address, &info ) == 0 )
            return false;
        if ( info.dli_fname == NULL )
            return false;
        dirname((char*)info.dli_fname); (1)

With info.dli_fname contains "./libabc.so". Before (1) is invoked, "info shared" command on gdb 7.1 shows no problem, but after invoking (1), "info shared" shows "." in Shared Object Library column and "No" in Sym column. After that, all "dlopen" functions failed with error "Error while mapping shared library sections" and some libraries throw Segmentation Fault exception. So, I think it is a bug of dirname function.
I hope this information is helpful. I'm looking forward to seeing a fix for this.

Sincerely,
Vinh T. Nguyen

[Message part 2 (text/html, inline)]

Message #10 received at 21056-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Vinh Nguyen <vnguyen <at> opswat.com>, 21056-done <at> debbugs.gnu.org
Cc: Dave Patt <dpatt <at> opswat.com>
Subject: Re: bug#21056: [BUG] Bug with dirname on Ubuntu
Date: Tue, 14 Jul 2015 10:21:33 -0600

[Message part 1 (text/plain, inline)]

tag 21056 notabug
thanks

On 07/14/2015 03:04 AM, Vinh Nguyen wrote:
> Dear Sir/Madam,
> I've found a bug with dirname function on Ubuntu 14.04 LTS. The context is:

Thanks for the report.  However, you have reached the coreutils list
(owners of dirname(1) for command line use), but you are complaining
about the libc function dirname(3) (for use in C programs); the two are
quite distinct.  This list is unable to change the libc behavior, so I'm
going to close the bug as invalid in the coreutils database.

>         Dl_info info;
>         if ( dladdr( ( const void* )function_to_get_address, &info ) == 0 )
>             return false;
>         if ( info.dli_fname == NULL )
>             return false;
>         dirname((char*)info.dli_fname); (1)

This is invalid use of dirname().  POSIX says that dirname() may modify
its argument, but you MUST NOT modify a const char * string; the fact
that you are casting away const should be a warning flag.  Furthermore,
the POSIX definition of dirname() says that it need not be threadsafe,
making it a pain to use in libraries that might be used in a threaded
context.  Finally, dirname() has fixed semantics that are wrong in code
intended to be portable to Windows file names with drive letters.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html

In short, the POSIX dirname() function is worthless; you CANNOT safely
use it on untrusted input.  The gnulib project has this to say about
dirname(), and recommends that you use gnulib's dir_name() instead
(which IS safe to use on untrusted input, but which malloc()s the result
so you have to adjust your code to free() the result):

https://www.gnu.org/software/gnulib/manual/html_node/dirname.html#dirname

> 
> With info.dli_fname contains "./libabc.so". Before (1) is invoked, "info shared" command on gdb 7.1 shows no problem, but after invoking (1), "info shared" shows "." in Shared Object Library column and "No" in Sym column. After that, all "dlopen" functions failed with error "Error while mapping shared library sections" and some libraries throw Segmentation Fault exception. So, I think it is a bug of dirname function.
> I hope this information is helpful. I'm looking forward to seeing a fix for this.

The fix is not to libc's dirname(), but to your code for invalid usage
of dirname().

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.