[Bug binutils/28995] [BUG] stack exhausion in nm-new, function demangle_const
https://sourceware.org/bugzilla/show_bug.cgi?id=28995 --- Comment #3 from han zheng --- Ack, thanks -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28885] dlltool broke in 2.38
https://sourceware.org/bugzilla/show_bug.cgi?id=28885 Mikael Pettersson changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #10 from Mikael Pettersson --- And now fixed on binutils-2_38-branch, closing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28933] buffer overflow on powerpc-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=28933 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by Nick Alcock : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=975b5540232ffe37c6c2ce37fa2b480c2d6cc0ab commit 975b5540232ffe37c6c2ce37fa2b480c2d6cc0ab Author: Nick Alcock Date: Fri Mar 18 00:49:11 2022 + libctf, ld: diagnose corrupted CTF header cth_strlen The last section in a CTF dict is the string table, at an offset represented by the cth_stroff header field. Its length is recorded in the next field, cth_strlen, and the two added together are taken as the size of the CTF dict. Upon opening a dict, we check that none of the header offsets exceed this size, and we check when uncompressing a compressed dict that the result of the uncompression is the same length: but CTF dicts need not be compressed, and short ones are not. Uncompressed dicts just use the ctf_size without checking it. This field is thankfully almost unused: it is mostly used when reserializing a dict, which can't be done to dicts read off disk since they're read-only. However, when opening an uncompressed foreign-endian dict we have to copy it out of the mmaped region it is stored in so we can endian- swap it, and we use ctf_size when doing that. When the cth_strlen is corrupt, this can overrun. Fix this by checking the ctf_size in all uncompressed cases, just as we already do in the compressed case. Add a new test. This came to light because various corrupted-CTF raw-asm tests had an incorrect cth_strlen: fix all of them so they produce the expected error again. libctf/ PR libctf/28933 * ctf-open.c (ctf_bufopen_internal): Always check uncompressed CTF dict sizes against the section size in case the cth_strlen is corrupt. ld/ PR libctf/28933 * testsuite/ld-ctf/diag-strlen-invalid.*: New test, derived from diag-cttname-invalid.s. * testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect cth_strlen. * testsuite/ld-ctf/diag-cttname-null.s: Likewise. * testsuite/ld-ctf/diag-cuname.s: Likewise. * testsuite/ld-ctf/diag-parlabel.s: Likewise. * testsuite/ld-ctf/diag-parname.s: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28933] buffer overflow on powerpc-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=28933 Nick Alcock changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Nick Alcock --- Done, and backported. Can backport further if anyone wants. My test matrix now includes a test run under valgrind with LIBCTF_WRITE_FOREIGN_ENDIAN=t set in the environment, and I have verified that setting this on a little-endian machine produces CTF identical to that written on a big-endian machine without that flag set. So we should now be testing the overflowing path routinely, and this should not recur. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28992] strip strips .gnu_debuglink
https://sourceware.org/bugzilla/show_bug.cgi?id=28992 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Cristian, Can you tell me how strip is being run ? In particular, are there any command line options in effect ? I tried to reproduce the problem like this: % readelf -SW testprog | grep debuglink [27] .gnu_debuglinkPROGBITS 00322c 18 00 0 0 4 % strip testprog -o fred % readelf -WS fred | grep debuglink [27] .gnu_debuglinkPROGBITS 00322c 18 00 0 0 4 This was not using strip from MinGW 11.2.0 however, but rather one built from the head of the development branch. So possibly there is a bug that jas already been fixed... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
Issue 43142 in oss-fuzz: binutils:fuzz_readelf: Timeout in fuzz_readelf
Updates: Labels: Deadline-Approaching Comment #2 on issue 43142 by sheriffbot: binutils:fuzz_readelf: Timeout in fuzz_readelf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43142#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
