[Bug binutils/20499] gprof: segmentation fault on invalid symbol file
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 Nick Clifton changed: What|Removed |Added Attachment #9465|0 |1 is obsolete|| Attachment #9468|0 |1 is obsolete|| --- Comment #6 from Nick Clifton --- Created attachment 9470 --> https://sourceware.org/bugzilla/attachment.cgi?id=9470&action=edit Proposed patch Hi Tobias, > The actual issue arises if the parsed line does not match "%s %c %s". This > pattern fills address, type, and name in that order. If the input is merely > "x", only "address" is filled, the others are left alone. Good point. It also shiws a weakness in my original patch, in that it did not address the true cause of the problem. I have uploaded another potential patch which I think should get both things right - it provides upper limits to the sscanf and fscanf calls, so that the string buffers cannot overflow, and it changes the loop in core_create_sym_from() so that only lines where the sscanf function succeeds are then converted into symbols. Please have a look and let me know what you think. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld 2.27: segfault on armv7h on input in 'binary' format
Hi redfish,
> $ touch foo.dat
> $ /usr/bin/ld -r -b binary -o /tmp/foo.o foo.dat
> Segmentation fault (core dumped)
Ah - snafu - fixed by this patch.
Cheers
Nick
bfd/ChangeLog
2016-08-23 Nick Clifton
* elf32-arm.c (elf32_arm_count_additional_relocs): Return zero if
there is no arm data associated with the section.
diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c
index 1eba21b..4478238 100644
--- a/bfd/elf32-arm.c
+++ b/bfd/elf32-arm.c
@@ -18688,7 +18688,7 @@ elf32_arm_count_additional_relocs (asection *sec)
{
struct _arm_elf_section_data *arm_data;
arm_data = get_arm_elf_section_data (sec);
- return arm_data->additional_reloc_count;
+ return arm_data == NULL ? 0 : arm_data->additional_reloc_count;
}
/* Called to set the sh_flags, sh_link and sh_info fields of OSECTION which
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/20507] New: version-script refuses to hide symbols called malloc/calloc
https://sourceware.org/bugzilla/show_bug.cgi?id=20507
Bug ID: 20507
Summary: version-script refuses to hide symbols called
malloc/calloc
Product: binutils
Version: 2.24
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: primiano at google dot com
CC: ian at airs dot com
Target Milestone: ---
The behavior of gold seems to diverge from the bfd linker when trying to hide
malloc/calloc symbols using a version script.
Minified repro:
$ cat< test.cc
extern "C" void* malloc(unsigned long size) { return 0; }
extern "C" void* calloc(unsigned long size) { return 0; }
extern "C" void* foobar(unsigned long size) { return 0; }
int main() { return 0; }
EOF
$ cat< test.lst
{ local: *; };
EOF
$ g++ -fuse-ld=gold -o out.gold test.cc -Wl,--version-script=test.lst
$ g++ -fuse-ld=bfd -o out.bfd test.cc -Wl,--version-script=test.lst
$ nm -C -D --defined-only out.bfd
$ nm -C -D --defined-only out.gold
004005dc T calloc
004005cd T malloc
I'd expect out.gold to not leak out the malloc/calloc symbols.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #17 from dave.anglin at bell dot net --- On 2016-08-22 9:07 PM, amodra at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=20464 > > --- Comment #16 from Alan Modra --- > Ah, mips64 or s390x needed to be added to the target list. > > I think the part of HJ's patch that forces SYM64 archives due to the mere > presence of mips64 or s390x in the --enable-targets list ought to be reverted. That sounds like a good idea. After further consideration, it didn't seem right to break consistency with existing code due to the presence of mips64 or s390x in the --enable-targets list. > As far as I can tell, this won't break mips64 or s390x. If any 64-bit target > actually needs a 64-bit armap due to archive size exceeding 4G, then you'll > get > that. Also, note that binutils-2.25 and binutils-2.26 created archives with > 32-bit armaps for mips64 and s390x if plugins were enabled. Wouldn't this also be possible on 32-bit targets with large file support and why can't these targets support both armaps automatically? Dave -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20499] gprof: segmentation fault on invalid symbol file
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=38334d6de448272c3bd831e3410dbc337fc2739d commit 38334d6de448272c3bd831e3410dbc337fc2739d Author: Nick Clifton Date: Tue Aug 23 15:41:01 2016 +0100 Better fix for PR 20499, including preventing strlen from being called on an uninitialised name field. PR gprof/20499 * corefile.c (BUFSIZE): Define. (STR_BUFSIZE): Define. (read_function_mappings): Use BUFSIZE and STR)BUFSIZE. (num_of_syms_in): Move buf, address and name arrays out of function and declare as static BUFSIZE arrays. Use STR_BUFSIZE when scanning for name and address. (core_create_syms_from): Revert previous delta. Instead short circuit the parsing of a symbol if all three fields could not be found. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20499] gprof: segmentation fault on invalid symbol file
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 --- Comment #9 from Nick Clifton --- Hi Tobias, > Now there's just the possible "num++" overflow on very large files left. > Could hit amd64 or i386 with large file support. It takes a huge symbol file > for that though. Right - and I think that other things would go wrong first. For example, I do not think that gprof is compiled with large file support enabled... So I have committed the revised patch. If you have any problems in this area, please let me know. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20499] gprof: segmentation fault on invalid symbol file
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 --- Comment #7 from Tobias Stoeckmann --- Oh, nice spotting with this "[^\n:]" parsing, I skipped validating that because this kind of expression was unknown to me. Always amazing to see what else pops up when more people look at the code! :) Yes, this patch looks correct. Now there's just the possible "num++" overflow on very large files left. Could hit amd64 or i386 with large file support. It takes a huge symbol file for that though. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20499] gprof: segmentation fault on invalid symbol file
https://sourceware.org/bugzilla/show_bug.cgi?id=20499 --- Comment #10 from Tobias Stoeckmann --- Challenge accepted. :D So I investigated this. It is in fact possible to crash gprof with a "num" overflow here. Let's consider the possible situations: AMD64: It is impossible to overflow a 64 bit size_t within sane boundaries. I might stand corrected in 2030 or whatever, but by today, we don't have such large files. Instead, we have to overflow "num" itself so it's back to zero. For that, we need a file consisting of 2^32 lines. The shortest valid line is 7 bytes, which makes this file around 28 GB in size. Granted, I didn't test this due to lack of patience. Let's instead go to... I386: Here, it is in fact possible to overflow a 32 bit size_t. We won't use a 28 GB file here, because it could be that gprof is compiled without large file support (in fact, my default binutils compilation supports large files). The size of a Sym struct is 200 bytes, so let's do the math: (SIZE_MAX+1) / sizeof(Sym) = 2^32 / 200 = 21474836.48 We want to overflow, so let's use 21474837 instead. As outlined before, the shortest valid line is 7 bytes, so we end up with a 143 MB file. That's manageable, even without large file support! Proof of Concept: $ for ((i = 0; i < 21474837; i++)) > do > echo "a t a" > done > syms $ gprof -S syms /bin/ls Segmentation fault Yes, the creation of syms can be sped up, but I don't want to cludder this report with a more comprehensive script. And yes, the segmentation fault resulted due to num-overflow, nothing else. Hope this report was enjoyable to read, at least it was fun to figure out a pathetic input like this again. :) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #18 from Alan Modra --- > Wouldn't this also be possible on 32-bit targets with large file support > and why can't these targets support both armaps automatically? They can and will if 64-bit bfd support is also enabled, modulo truncation bugs. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
