[Bug binutils/4110] Broken object file crashes nm
https://sourceware.org/bugzilla/show_bug.cgi?id=4110 Alan Modra changed: What|Removed |Added Status|WAITING |RESOLVED CC||amodra at gmail dot com Resolution|--- |FIXED --- Comment #23 from Alan Modra --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/4110] Broken object file crashes nm
https://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- Comment #22 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=327301a4604da40da264c554daa8c1e97aa2fbe2 commit 327301a4604da40da264c554daa8c1e97aa2fbe2 Author: Alan Modra Date: Fri Jan 31 00:53:59 2020 +1030 OOM in setup_group We alloc, seek and read using section sizes in object files. Fuzzed objects can have silly sizes, but that's OK if the system supports memory over-commit. The read fails because we hit EOF and that usually results in a graceful exit. But if we memset before the read then the invalid size results in attempting to write to a huge number of memory pages, and an eventual Out Of Memory after probably swapping like crazy. So don't memset. There really isn't a need to clear the section contents anyway. All bytes are written with a good object file by the read and following loop converting section index in target order to ELF section header pointer, and the only untidy bytes are the 4 bytes past the group flags when pointers are 8 bytes. Those don't matter but the patch clears them for anyone poking around in a debugger. On error paths it's as good to free section contents as it is to clear them. Noticed when looking at PR4110 fourth test case. PR 4110 * elf.c (setup_group): Don't clear entire section contents, just the padding after group flags. Release alloc'd memory after a seek or read failure. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Bug binutils/4110] Broken object file crashes nm
Hi Sami,
Right, first of all, I have checked in the patch as it currently
exists (patch.5). We will be branching for release 2.18 at some point
in the near future and I want to make sure that the error checking we
have already developed gets into that release. I added this ChangeLog
entry:
bfd/ChangeLog
PR binutils/4110
* elf.c (IS_VALID_GROUP_SECTION_HEADER): New macro.
(setup_group): Use it. Report corrupt group section headers.
(bfd_section_from_shdr): Use new macro. Replace constant 4 with
GRP_ENTRY_SIZE. Cope with NULLs in the group section table.
(elf_fake_section): Replace constant 4 with GRP_ENTRY_SIZE.
Sorry for taking some time to reply. It seems I can't reproduce the SEGV
anymore myself (don't know what changed), but I do get a valgrind error. And I
also have a log of nm crashing twice on that input file. By the way now that I
test I also get the same Valgrind error with broken3.o and broken4.o. It seems
the uninitialized variable has to be still idx-shdr as probably was the case
with broken4.o, however I can't get that either to crash any more.
==15602== Conditional jump or move depends on uninitialised value(s)
==15602==at 0x433A71: bfd_section_from_shdr (elf.c:2181)
(gdb) print idx
$1 = (Elf_Internal_Group *) 0x4d5c9f0
(gdb) print *idx
$2 = {shdr = 0x0, flags = 0}
(gdb) l
2176 idx += n_elt;
2177 while (--n_elt != 0)
2178{
2179 --idx;
2180
2181 if (idx-shdr != NULL
2182 (s = idx-shdr-bfd_section) != NULL
2183 elf_next_in_group (s) != NULL)
2184{
2185 elf_next_in_group (hdr-bfd_section) = s;
Hmm, I do not see how the idx-shdr array can be uninitialized... I did
find another place in elf.c where we assume that the group section
contents will always be valid pointers, hence I am uploading another
patch to fix that. But I doubt if that will resolve the valgrind issue.
I think that we need a seg-faulting test case before we can proceed
any further.
(Just as a guess, do you get a seg fault if you run any of the tests
with the environment variable MALLOC_CHECK_ set to 2 ? I tried, but
they all ran OK).
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From sliedes at cc dot hut dot fi 2007-03-25 17:13
---
Sorry for taking some time to reply. It seems I can't reproduce the SEGV
anymore myself (don't know what changed), but I do get a valgrind error. And I
also have a log of nm crashing twice on that input file. By the way now that I
test I also get the same Valgrind error with broken3.o and broken4.o. It seems
the uninitialized variable has to be still idx-shdr as probably was the case
with broken4.o, however I can't get that either to crash any more.
Here's what I get from Valgrind:
--
$ valgrind --db-attach=yes binutils/nm-new ~/bug/nm-broken6.o
==15602== Memcheck, a memory error detector.
==15602== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==15602== Using LibVEX rev 1732, a library for dynamic binary translation.
==15602== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==15602== Using valgrind-3.2.3-Debian, a dynamic binary instrumentation
framework.
==15602== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==15602== For more details, rerun with: -v
==15602==
BFD: /home/sliedes/bug/nm-broken6.o: invalid string offset 798 = 8 for section
`.group'
==15602== Conditional jump or move depends on uninitialised value(s)
==15602==at 0x433A71: bfd_section_from_shdr (elf.c:2181)
==15602==by 0x42C1C7: bfd_elf64_object_p (elfcode.h:850)
==15602==by 0x41160E: bfd_check_format_matches (format.c:240)
==15602==by 0x403F89: display_file (nm.c:1179)
==15602==by 0x404BB5: main (nm.c:1622)
==15602==
==15602== Attach to debugger ? --- [Return/N/n/Y/y/C/c] y
starting debugger
==15602== starting debugger with cmd: /usr/bin/gdb -nw /proc/15859/fd/1014
15859
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as x86_64-linux-gnu...
Using host libthread_db library /usr/lib/debug/libthread_db.so.1.
Attaching to program: /proc/15859/fd/1014, process 15859
Reading symbols from /usr/lib/valgrind/amd64-linux/vgpreload_core.so...done.
Loaded symbols for /usr/lib/valgrind/amd64-linux/vgpreload_core.so
Reading symbols
from /usr/lib/valgrind/amd64-linux/vgpreload_memcheck.so...done.
Loaded symbols for /usr/lib/valgrind/amd64-linux/vgpreload_memcheck.so
Reading symbols from /usr/lib/debug/libc.so.6...done.
Loaded symbols for /usr/lib/debug/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols
from /usr/lib/debug/lib/ld-2.3.6.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00433a71 in bfd_section_from_shdr (abfd=0x4d5c118, shindex=1) at
elf.c:2181
2181 if (idx-shdr != NULL
(gdb) print idx
$1 = (Elf_Internal_Group *) 0x4d5c9f0
(gdb) print *idx
$2 = {shdr = 0x0, flags = 0}
(gdb) l
2176 idx += n_elt;
2177 while (--n_elt != 0)
2178{
2179 --idx;
2180
2181 if (idx-shdr != NULL
2182 (s = idx-shdr-bfd_section) != NULL
2183 elf_next_in_group (s) != NULL)
2184{
2185 elf_next_in_group (hdr-bfd_section) = s;
(gdb)
--
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4110
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-22 12:23 --- Hi Sami, Hmm, This one did not break the nm and ld executables that I have here. Could you send me the valgrind/gdb outputs like before so I can take a stab at where the problem is happening ? Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From sliedes at cc dot hut dot fi 2007-03-21 15:47 --- Created an attachment (id=1640) -- (http://sourceware.org/bugzilla/attachment.cgi?id=1640action=view) Test case Yes, that fixes that problem for that test case. I updated to HEAD and applied patch.4, now with the attached test case, I get a SEGV instead of Memory exhausted which I get with patch.3. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-21 16:26 --- Created an attachment (id=1641) -- (http://sourceware.org/bugzilla/attachment.cgi?id=1641action=view) Improve error detection when a group section header's size field is corrupt -- What|Removed |Added Attachment #1623 is|0 |1 obsolete|| Attachment #1631 is|0 |1 obsolete|| http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-21 16:29 --- Hi Sami, New patch uploaded. Now you should get a more reasonable error code from nm )Bad value) and the linker should not seg fault. Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From sliedes at cc dot hut dot fi 2007-03-22 04:08 --- Created an attachment (id=1642) -- (http://sourceware.org/bugzilla/attachment.cgi?id=1642action=view) Test case Ok, one more, after quite a lot of testing. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-20 10:53 --- Created an attachment (id=1631) -- (http://sourceware.org/bugzilla/attachment.cgi?id=1631action=view) patch.3 + zero-initialise memory allocated for group date -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From sliedes at cc dot hut dot fi 2007-03-17 13:48
---
Created an attachment (id=1626)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=1626action=view)
One more test case
With patch.3 it's starting to look quite robust, I had to try a lot of things
to break it :) Here's one that breaks it only in some very obscure cases, so
I'll attach Valgrind output from a case where it does not crash and a backtrace
from a crash in case you are unable to reproduce. (It just happens that the
uninitialized idx-shr is usually NULL, and under some obscure conditions I got
it to be 0x100 in the backtrace).
-- Valgrind output --
$ valgrind ~/rec/binutils/binutils/nm-new broken.o
==9440== Memcheck, a memory error detector.
==9440== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==9440== Using LibVEX rev 1732, a library for dynamic binary translation.
==9440== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==9440== Using valgrind-3.2.3-Debian, a dynamic binary instrumentation
framework.
==9440== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==9440== For more details, rerun with: -v
==9440==
BFD: broken.o: invalid string offset 798 = 8 for section `.group'
==9440== Conditional jump or move depends on uninitialised value(s)
==9440==at 0x42BC4A: bfd_section_from_shdr (elf.c:2171)
==9440==by 0x41EE4B: bfd_elf64_object_p (elfcode.h:850)
==9440==by 0x40CAEC: bfd_check_format_matches (format.c:240)
==9440==by 0x4039F4: display_file (nm.c:1179)
==9440==by 0x403F3A: main (nm.c:1622)
BFD: broken.o: invalid string offset 814 = 8 for section `.group'
BFD: broken.o: invalid string offset 836 = 8 for section `.group'
BFD: broken.o: invalid string offset 1068 = 8 for section `.group'
BFD: broken.o: invalid string offset 2524 = 8 for section `.group'
BFD: broken.o: invalid string offset 65838 = 309 for section `.shstrtab'
BFD: broken.o: invalid string offset 2511 = 8 for section `.group'
/home/sliedes/rec/binutils/binutils/nm-new: broken.o: File truncated
==9440==
==9440== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1)
==9440== malloc/free: in use at exit: 0 bytes in 0 blocks.
==9440== malloc/free: 15 allocs, 15 frees, 52,954 bytes allocated.
==9440== For counts of detected errors, rerun with: -v
==9440== All heap blocks were freed -- no leaks are possible.
--
-- Backtrace --
(gdb) r
Starting program: /home/sliedes/rec/binutils/binutils/nm-new smodels.o
BFD: smodels.o: invalid string offset 798 = 520 for section `*group'
Program received signal SIGSEGV, Segmentation fault.
0x0042bc4c in bfd_section_from_shdr (abfd=0x5ac400, shindex=1) at
elf.c:2171
2171 if (idx-shdr != NULL
(gdb) l
2166 idx += n_elt;
2167 while (--n_elt != 0)
2168{
2169 --idx;
2170
2171 if (idx-shdr != NULL
2172 (s = idx-shdr-bfd_section) != NULL
2173 elf_next_in_group (s) != NULL)
2174{
2175 elf_next_in_group (hdr-bfd_section) = s;
(gdb) print *idx
$2 = {shdr = 0x100, flags = 256}
(gdb) bt
#0 0x0042bc4c in bfd_section_from_shdr (abfd=0x5ac400, shindex=1) at
elf.c:2171
#1 0x0041ee4c in bfd_elf64_object_p (abfd=0x5ac400) at elfcode.h:850
#2 0x0040caed in bfd_check_format_matches (abfd=0x5ac400,
format=value optimized out, matching=0x7fff07a2cac8) at format.c:240
#3 0x004039f5 in display_file (filename=0x7fff07a2d4bc smodels.o) at
nm.c:1179
#4 0x00403f3b in main (argc=2, argv=0x7fff07a2cc08) at nm.c:1622
(gdb) bt full
#0 0x0042bc4c in bfd_section_from_shdr (abfd=0x5ac400, shindex=1) at
elf.c:2171
idx = (Elf_Internal_Group *) 0x5add50
n_elt = 104
s = (asection *) 0x0
hdr = (Elf_Internal_Shdr *) 0x5bce18
name = value optimized out
#1 0x0041ee4c in bfd_elf64_object_p (abfd=0x5ac400) at elfcode.h:850
num_sec = 34
x_ehdr = {e_ident =
\177ELF\002\001\001\000\000\000\000\000\000\000\000, e_type = \001,
e_machine = , e_version = \001\000\000,
e_entry = \000\000\000\000\000\000\000, e_phoff =
\000\000\000\000\000\000\000, e_shoff = \220K\000\000\000\000\000, e_flags
= \000\000\000,
e_ehsize = @, e_phentsize = \000, e_phnum = \000, e_shentsize = @,
e_shnum = \, e_shstrndx = \037}
i_ehdrp = value optimized out
x_shdr = {sh_name = \t\000\000, sh_type = \003\000\000, sh_flags =
\000\000\000\000\000\000\000, sh_addr = \000\000\000\000\000\000\000,
sh_offset = `\000\000\000\000\000, sh_size = \017\n\000\000\000\000\000,
sh_link = \000\000\000, sh_info = \000\000\000,
sh_addralign = \001\000\000\000\000\000\000, sh_entsize =
\000\000\000\000\000\000\000}
i_shdr = {sh_name = 0, sh_type = 0, sh_flags = 0, sh_addr = 0, sh_size
= 0, sh_entsize = 0, sh_link = 0, sh_info = 0, sh_offset = 0,
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-16 15:34 --- Created an attachment (id=1621) -- (http://sourceware.org/bugzilla/attachment.cgi?id=1621action=view) Revised form of previous patch without the loop rewriting. -- What|Removed |Added Attachment #1590 is|0 |1 obsolete|| http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-16 15:36 --- Hi Sami, Please could you try the newly upload revised patch. If you have the old patch applied to your sources, please remove that one first. (I think that my first version was a little bit over enthusiastic...) Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From sliedes at cc dot hut dot fi 2007-03-16 20:59 --- HEAD + 4110.elf.c.patch.2 does not crash with either the test case in this bug or the one I mistakenly attached to #4109. However I still could generate one broken enough that crashes nm. I'll attach that one. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From sliedes at cc dot hut dot fi 2007-03-16 21:00 --- Created an attachment (id=1622) -- (http://sourceware.org/bugzilla/attachment.cgi?id=1622action=view) Still one more file that crashes nm -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-17 06:25 --- Created an attachment (id=1623) -- (http://sourceware.org/bugzilla/attachment.cgi?id=1623action=view) Add more tests for broken object files -- What|Removed |Added Attachment #1621 is|0 |1 obsolete|| http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-17 06:26 --- Hi Sami, Patch version 3 has now been uploaded :-) Please give it a whirl. Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From nickc at redhat dot com 2007-03-02 09:16 --- Hi Sami, Please try the attached patch which I think should resolve this problem for you. Cheers Nick -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4110] Broken object file crashes nm
--- Additional Comments From sliedes at cc dot hut dot fi 2007-03-02 21:07 --- Yes, this fixes it for the file I attached in this bug. I meant to attach a new one with a comment, but mistakenly attached it to #4109. Here's another one that crashes nm: http://sourceware.org/bugzilla/attachment.cgi?id=1593action=view Please also see the comments backtrace: http://sourceware.org/bugzilla/show_bug.cgi?id=4109#c3 -- http://sourceware.org/bugzilla/show_bug.cgi?id=4110 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
