Created attachment 11584 [details] input file triggering the bug Hi, there. I got a segment fault when testing nm-new in binutils-2.30 with the command `nm-new -a -C -l --synthetic poc`. The compilation flags used were "-g -O2". The stack dumps given by valgrind are as follows: Stack dump: ==10084== Invalid read of size 8 ==10084== at 0x403B55: print_symbol (nm.c:989) ==10084== by 0x403F73: print_symbols (nm.c:1089) ==10084== by 0x403F73: display_rel_file (nm.c:1205) ==10084== by 0x4050D9: display_file (nm.c:1325) ==10084== by 0x402FA9: main (nm.c:1799) ==10084== Address 0x20 is not stack'd, malloc'd or (recently) free'd
(In reply to zhangyn2012 from comment #0) Hi Zhangyn, Thank you for reporting this problem. Unfortunately I am unable to reproduce it. > I got a segment fault when testing nm-new in binutils-2.30 2.30 is a slightly old release. Please could you try with the latest release sources (2.32) or, even better, the current mainline development sources. > The compilation flags used were "-g -O2". How was the toolchain configured ? Also, were you running these tests on a 32-bit host or a 64-bit host ? > ==10084== Invalid read of size 8 > ==10084== at 0x403B55: print_symbol (nm.c:989) > ==10084== by 0x403F73: print_symbols (nm.c:1089) Are you able to use a debugger to narrow down what is going wrong ? Cheers Nick
(In reply to Nick Clifton from comment #1) Hi Nick, > How was the toolchain configured ? Also, were you running these tests > on a 32-bit host or a 64-bit host ? I ran the tests on a 64-bit host. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.11' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) > Are you able to use a debugger to narrow down what is going wrong ? I debugged and found that in the loop of nm.c:983, when j increased to 44, a null pointer dereference is triggered because though it checks r->sym_ptr_ptr is not null, *r->sym_ptr_ptr is a null pointer. nm.c:989 accesses *r->sym_ptr_ptr->section which causes the program to crash. Program received signal SIGSEGV, Segmentation fault. 0x0000000000403b55 in print_symbol (abfd=abfd@entry=0x7172a0, sym=0x71a660, ssiz e=ssize@entry=0, archive_bfd=archive_bfd@entry=0x0) at nm.c:989 1: j = 44 2: r->sym_ptr_ptr = (struct bfd_symbol **) 0x71a8a8 3: *r->sym_ptr_ptr = (struct bfd_symbol *) 0x0
The binutils-2_30-branch branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c6f021093dbd26b4d8e761e9a19af817e9f2561f commit c6f021093dbd26b4d8e761e9a19af817e9f2561f Author: Nick Clifton <nickc@redhat.com> Date: Mon Feb 11 16:15:59 2019 +0000 Fix a NULL pointer dereference in nm, when parsing a corrupt file. PR 24168 * nm.c (print_symbol): Check for NULL contents of the sym_ptr_ptr field.
(In reply to zhangyn2012 from comment #2) Hi Zhangyn, > I debugged and found that in the loop of nm.c:983, when j increased to 44, a > null pointer dereference is triggered because though it checks > r->sym_ptr_ptr is not null, *r->sym_ptr_ptr is a null pointer. nm.c:989 > accesses *r->sym_ptr_ptr->section which causes the program to crash. Thanks - that help me to reproduce the problem. I have checked in a fix to the 2.30 branch. As far I was able to tell this problem has already been fixed from 2.31 onwards, although I did not spend the time to track down the exact commit that fixed the bug. Cheers Nick