[Bug gprofng/29102] New: gprofng: assertion in gprofng/src/Expression.cc:139
https://sourceware.org/bugzilla/show_bug.cgi?id=29102 Bug ID: 29102 Summary: gprofng: assertion in gprofng/src/Expression.cc:139 Product: binutils Version: 2.39 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: vladimir.mezentsev at oracle dot com Target Milestone: --- It's a regression in QLparser since we started using bison To reproduce, set a filter: % gprofng display text -filter '(1,2) SOME IN STACK' -func test.1.er current filter setting: "(1,2) SOME IN STACK" gp-display-text: gprofng/src/Expression.cc:139: void Expression::fixupValues(): Assertion `arg0 && v.next == &(arg0->v)' failed. Aborted (core dumped) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29087] "non-canonical reference to canonical protected function" with protected visibility, -mno-direct-extern-access and virtual functions
https://sourceware.org/bugzilla/show_bug.cgi?id=29087 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.39 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from H.J. Lu --- Fixed for 2.39 and 2.38 branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29087] "non-canonical reference to canonical protected function" with protected visibility, -mno-direct-extern-access and virtual functions
https://sourceware.org/bugzilla/show_bug.cgi?id=29087 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9c67f6382ac2c90fbde5729feaf7d59ce662147a commit 9c67f6382ac2c90fbde5729feaf7d59ce662147a Author: H.J. Lu Date: Tue Apr 26 09:08:54 2022 -0700 x86: Properly handle function pointer reference Update commit ebb191adac4ab45498dec0bfaac62f0a33537ba4 Author: H.J. Lu Date: Wed Feb 9 15:51:22 2022 -0800 x86: Disallow invalid relocation against protected symbol to allow function pointer reference and make sure that PLT entry isn't used for function reference due to function pointer reference. bfd/ PR ld/29087 * elf32-i386.c (elf_i386_scan_relocs): Don't set pointer_equality_needed nor check non-canonical reference for function pointer reference. * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. ld/ PR ld/29087 * testsuite/ld-x86-64/x86-64.exp: Run PR ld/29087 tests. * testsuite/ld-x86-64/protected-func-3.c: New file. (cherry picked from commit 68c4956b1401de70173848a6bdf620cb42fa9358) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29087] "non-canonical reference to canonical protected function" with protected visibility, -mno-direct-extern-access and virtual functions
https://sourceware.org/bugzilla/show_bug.cgi?id=29087 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=68c4956b1401de70173848a6bdf620cb42fa9358 commit 68c4956b1401de70173848a6bdf620cb42fa9358 Author: H.J. Lu Date: Tue Apr 26 09:08:54 2022 -0700 x86: Properly handle function pointer reference Update commit ebb191adac4ab45498dec0bfaac62f0a33537ba4 Author: H.J. Lu Date: Wed Feb 9 15:51:22 2022 -0800 x86: Disallow invalid relocation against protected symbol to allow function pointer reference and make sure that PLT entry isn't used for function reference due to function pointer reference. bfd/ PR ld/29087 * elf32-i386.c (elf_i386_scan_relocs): Don't set pointer_equality_needed nor check non-canonical reference for function pointer reference. * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. ld/ PR ld/29087 * testsuite/ld-x86-64/x86-64.exp: Run PR ld/29087 tests. * testsuite/ld-x86-64/protected-func-3.c: New file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22263] -fpie -pie generates dynamic relocations in text section
https://sourceware.org/bugzilla/show_bug.cgi?id=22263 --- Comment #26 from cvs-commit at gcc dot gnu.org --- The binutils-2_37-branch branch has been updated by Andreas Krebbel : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e20961e9f9d058fab00ce511b429570a901396e6 commit e20961e9f9d058fab00ce511b429570a901396e6 Author: Stefan Liebler Date: Thu Apr 28 14:29:58 2022 +0200 s390: Avoid dynamic TLS relocs in PIE No dynamic relocs are needed for TLS defined in an executable, the TP relative offset is known at link time. Fixes FAIL: Build pr22263-1 bfd/ PR ld/22263 * elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll instead of bfd_link_pic for TLS. (elf_s390_check_relocs): Likewise. (allocate_dynrelocs): Likewise. (elf_s390_relocate_section): Likewise. (cherry picked from commit 26b1426577b5dcb32d149c64cca3e603b81948a9) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22263] -fpie -pie generates dynamic relocations in text section
https://sourceware.org/bugzilla/show_bug.cgi?id=22263 --- Comment #25 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by Andreas Krebbel : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=82a5bb730a16f8c7962568030268e784b4fb42c8 commit 82a5bb730a16f8c7962568030268e784b4fb42c8 Author: Stefan Liebler Date: Thu Apr 28 14:29:58 2022 +0200 s390: Avoid dynamic TLS relocs in PIE No dynamic relocs are needed for TLS defined in an executable, the TP relative offset is known at link time. Fixes FAIL: Build pr22263-1 bfd/ PR ld/22263 * elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll instead of bfd_link_pic for TLS. (elf_s390_check_relocs): Likewise. (allocate_dynrelocs): Likewise. (elf_s390_relocate_section): Likewise. (cherry picked from commit 26b1426577b5dcb32d149c64cca3e603b81948a9) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/22263] -fpie -pie generates dynamic relocations in text section
https://sourceware.org/bugzilla/show_bug.cgi?id=22263 --- Comment #24 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Andreas Krebbel : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=26b1426577b5dcb32d149c64cca3e603b81948a9 commit 26b1426577b5dcb32d149c64cca3e603b81948a9 Author: Stefan Liebler Date: Thu Apr 28 14:29:58 2022 +0200 s390: Avoid dynamic TLS relocs in PIE No dynamic relocs are needed for TLS defined in an executable, the TP relative offset is known at link time. Fixes FAIL: Build pr22263-1 bfd/ PR ld/22263 * elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll instead of bfd_link_pic for TLS. (elf_s390_check_relocs): Likewise. (allocate_dynrelocs): Likewise. (elf_s390_relocate_section): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29099] Buffer overflow can happen at libiberty/argv.c
https://sourceware.org/bugzilla/show_bug.cgi?id=29099 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #4 from Nick Clifton --- Hi yguoaz, Thanks for reporting this problem. Unfortunately the libiberty library is actually maintained by the GCC project, rather than the binutils, so you will need to report the issue using their bug reporting system: https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc Also - as Andreas points out, in order for pos to be LONG_MAX you would have to have a file that is so big that it could not possibly be read into a buffer. Even if running on a 32-bit system, a 4GB file would be too much to read into a buffer, even if the memory for it could be allocated. Plus as Alan has pointed out the multiplication will convert to a size_t, so the overflow is extremely unlikely. In other words, please do feel to report this bug to the gcc community if you wish, but it is unlikely that there will ever by a real world sceanario where this problem could be triggered. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29099] Buffer overflow can happen at libiberty/argv.c
https://sourceware.org/bugzilla/show_bug.cgi?id=29099 --- Comment #3 from Alan Modra --- "pos * sizeof (char)" might look to be a useless multiplication by 1, but it also converts the expression to size_t. size_t is an unsigned integer type. There is no signed integer overflow here, unless size_t is a smaller type than long. Even though the C standard allows that, I doubt there are any systems around that might be running this code where that is the case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29101] New: [Bug] User input is not sanitized in libdep_plugin.c and cause trouble on 32bit machine
https://sourceware.org/bugzilla/show_bug.cgi?id=29101
Bug ID: 29101
Summary: [Bug] User input is not sanitized in libdep_plugin.c
and cause trouble on 32bit machine
Product: binutils
Version: 2.38
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: yguoaz at gmail dot com
Target Milestone: ---
In the file ld/libdep_pugin.c, the function get_libdeps has the following code:
(link:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/libdep_plugin.c;h=5569aa45e360be6321a94fe7f3b2af1caf3fd163;hb=20756b0fbe065a84710aa38f2457563b57546440#l108)
static enum ld_plugin_status
get_libdeps (int fd)
{
arhdr ah;
int len;
...
for (;;)
{
len = read (fd, (void *) , sizeof (ah));
if (len != sizeof (ah))
break;
mlen = strtoul (ah.ar_size, NULL, 10);
if (!mlen || strncmp (ah.ar_name, LIBDEPS, sizeof (LIBDEPS)-1))
{
lseek (fd, mlen, SEEK_CUR);
continue;
}
lr = malloc (sizeof (linerec) + mlen);
...
}
}
where the definition of type arhdr is as follows:
typedef struct arhdr
{
char ar_name[16];
char ar_date[12];
char ar_uid[6];
char ar_gid[6];
char ar_mode[8];
char ar_size[10];
char ar_fmag[2];
} arhdr;
It is therefore possible to craft the file content and parse mlen to UINT32_MAX
(just manipulate the string content starting at ah.ar_size).
This will lead to an integer overflow for the calculation of the allocation
size: sizeof (linerec) + mlen (assuming a 32bit environment where unsigned long
takes 4 bytes). If this happens, accessing the buffer lr will lead to buffer
overflow in later code.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/29101] [Bug] User input is not sanitized in libdep_plugin.c and cause trouble on 32bit machine
https://sourceware.org/bugzilla/show_bug.cgi?id=29101 yguoaz at gmail dot com changed: What|Removed |Added CC||hyc at symas dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29099] Buffer overflow can happen at libiberty/argv.c
https://sourceware.org/bugzilla/show_bug.cgi?id=29099 --- Comment #2 from yguoaz at gmail dot com --- (In reply to Andreas Schwab from comment #1) > I don't think it is possible to create a file that large. In 32bit machine, long only takes 4 bytes. Therefore, maybe a 4GB sized-file is not very uncommon? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29099] Buffer overflow can happen at libiberty/argv.c
https://sourceware.org/bugzilla/show_bug.cgi?id=29099 --- Comment #1 from Andreas Schwab --- I don't think it is possible to create a file that large. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprof/29100] Buffer overflow when read function mapping file
https://sourceware.org/bugzilla/show_bug.cgi?id=29100 yguoaz at gmail dot com changed: What|Removed |Added CC||rth at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprof/29100] Buffer overflow when read function mapping file
https://sourceware.org/bugzilla/show_bug.cgi?id=29100 yguoaz at gmail dot com changed: What|Removed |Added CC||rth at sources dot redhat.com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprof/29100] New: Buffer overflow when read function mapping file
https://sourceware.org/bugzilla/show_bug.cgi?id=29100
Bug ID: 29100
Summary: Buffer overflow when read function mapping file
Product: binutils
Version: 2.38
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gprof
Assignee: unassigned at sourceware dot org
Reporter: yguoaz at gmail dot com
Target Milestone: ---
In the file gprof/corefile.c, the function read_function_mappings has the
following code:
(link:https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gprof/corefile.c;h=2838d49f9d22926affc5a62bd351bbdf914d51cd;hb=20756b0fbe065a84710aa38f2457563b57546440#l121)
static void
read_function_mappings (const char *filename)
{
FILE * file = fopen (filename, "r");
int count = 0;
while (!feof (file)) {
...
matches = fscanf (file, "%" STR_BUFSIZE "[^\n]\n", dummy);
if (!matches)
parse_error (filename);
count++;
}
symbol_map = ((struct function_map *)
xmalloc (count * sizeof (struct function_map)));
// code that writes to symbol_map
}
The value of the variable count is determined how many matches we get from the
input file. It could be a really large value, e.g., close to INT_MAX.
Then the computation of the allocation size "count * sizeof (struct
function_map)" may trigger an integer overflow and thus leads to a small buffer
allocated. This will lead to subsequent buffer overflows.
--
You are receiving this mail because:
You are on the CC list for the bug.
