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

Previous Next

Package: coreutils;

Reported by: Vinh Nguyen <vnguyen <at> opswat.com>

Date: Tue, 14 Jul 2015 15:26:01 UTC

Severity: normal

Done: Eric Blake <eblake <at> redhat.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eric Blake <eblake <at> redhat.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#21056: closed ([BUG] Bug with dirname on Ubuntu)
Date: Tue, 14 Jul 2015 16:22:01 +0000
[Message part 1 (text/plain, inline)]
Your message dated Tue, 14 Jul 2015 10:21:33 -0600
with message-id <55A5370D.2050805 <at> redhat.com>
and subject line Re: bug#21056: [BUG] Bug with dirname on Ubuntu
has caused the debbugs.gnu.org bug report #21056,
regarding [BUG] Bug with dirname on Ubuntu
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
21056: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21056
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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 3 (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 4 (text/html, inline)]
[Message part 5 (message/rfc822, inline)]
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 6 (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)]

This bug report was last modified 10 years ago.

Previous Next


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