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
Description: OpenPGP digital signature
--- End Message ---