bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21056: [BUG] Bug with dirname on Ubuntu


From: Eric Blake
Subject: bug#21056: [BUG] Bug with dirname on Ubuntu
Date: Tue, 14 Jul 2015 10:21:33 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]