[Bug binutils/28402] fail to allocate error in objdump at objalloc.c:143
https://sourceware.org/bugzilla/show_bug.cgi?id=28402 --- Comment #1 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=1808483c2f3f323d8e0398282251a85cd956321b commit 1808483c2f3f323d8e0398282251a85cd956321b Author: Alan Modra Date: Wed Oct 6 13:38:42 2021 +1030 PR28402, fail to allocate line number array This fixes a situation where the COFF code allocated memory for internal representaion arrays before reading the external file data. That meant the allocation didn't have any sanity check against file size. PR 28402 * coffcode.h (buy_and_read): Malloc rather than alloc memory. (coff_slurp_line_table): Read native line number info before allocating memory for internal line number array. Adjust error paths to suit. Remove now unnecessary line number count check. (coff_slurp_reloc_table): Adjust to suit buy_and_read change. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28420] segv in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28420 --- Comment #1 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=1992e26ec4498bdd08fa960b449f6fa29e5759fa commit 1992e26ec4498bdd08fa960b449f6fa29e5759fa Author: Alan Modra Date: Wed Oct 6 17:31:31 2021 +1030 PR28420, ecoff fuzzing failures PR 28420 * coff-mips.c (mips_adjust_reloc_in): Replace abort with error message and return. * ecoff.c (ecoff_slurp_reloc_table): Remove assertion and aborts, instead handle errors gracefully. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28402] fail to allocate error in objdump at objalloc.c:143
https://sourceware.org/bugzilla/show_bug.cgi?id=28402 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.38 --- Comment #2 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28420] segv in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28420 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.38 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28420] segv in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28420 --- Comment #3 from Alan Modra --- *** Bug 28421 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28421] SEGV in objdump at dump_reloc_set objdump.c:4636
https://sourceware.org/bugzilla/show_bug.cgi?id=28421 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Alan Modra --- Fixed with the patch for pr28420 *** This bug has been marked as a duplicate of bug 28420 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28422] use-after-free in objdump at get_build_id (./bfd/opncls.c:1864)
https://sourceware.org/bugzilla/show_bug.cgi?id=28422 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-10-06 Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28410] Prevent region check failures when relaxation is not final
https://sourceware.org/bugzilla/show_bug.cgi?id=28410 --- Comment #6 from lewis.revill at embecosm dot com --- (In reply to Nelson Chu from comment #4) > I assume we are talking about the option 3? If so, then there are some > thoughts that might help: I was thinking more about option 2. If I were to rewrite the system of restarting the whole set of relax passes without modifying `again` it should solve this bug. However I do need to understand the original motivation for restarting the set of relax passes to know whether it would be sufficient to only restart the relax passes themselves or whether we need to include that whole lang_relax_sections logic each time. Does that make sense? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/28417] std::string no longer allows accepting nullptr_t since it is undefined behavior after yesterday's change on libstdc++.
https://sourceware.org/bugzilla/show_bug.cgi?id=28417 Martin Liska changed: What|Removed |Added CC||mliska at suse dot cz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28423] use-after-free in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28423 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-10-07 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28415] stack-buffer-overflow in objdump at disassemble_bytes (objdump.c:2905)
https://sourceware.org/bugzilla/show_bug.cgi?id=28415
Guillermo E. Martinez changed:
What|Removed |Added
CC||guillermo.e.martinez@oracle
||.com
--- Comment #1 from Guillermo E. Martinez ---
Hello,
This is happening because cache_bread_1 it's reading less bytes than expected
(3314/6144 in .xt.insn for "property xtensa section")
bfd/cache.c:cache_bread_1: 0xcf2 ()
So _bfd_generic_get_section_contents is returning *false* and propagated to
bfd_get_section_contents, bfd_get_full_section_contents,
bfd_malloc_and_get_section and finally retrieve_contents.
After that, *table_data* variable is not taking care of the return value for
retrieve_contents assuming valid bytes for such section, further used in
bfd_get_32:
bfd_vma address = bfd_get_32 (abfd, table_data + off);
I thinks that it could be fixed as follow:
diff --git a/bfd/elf32-xtensa.c b/bfd/elf32-xtensa.c
index e5bfbb2f509..98039757c22 100644
--- a/bfd/elf32-xtensa.c
+++ b/bfd/elf32-xtensa.c
@@ -910,7 +910,14 @@ xtensa_read_table_entries (bfd *abfd,
table_entry_size -= 4;
num_records = table_size / table_entry_size;
+
table_data = retrieve_contents (abfd, table_section, true);
+ if (table_data == 0)
+{
+ *table_p = NULL;
+ return 0;
+}
+
blocks = (property_table_entry *)
bfd_malloc (num_records * sizeof (property_table_entry));
block_count = 0;
Please let me know your comments,
Kind regards,
Guillermo
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/28422] use-after-free in objdump at get_build_id (./bfd/opncls.c:1864)
https://sourceware.org/bugzilla/show_bug.cgi?id=28422 --- Comment #1 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=6d661cdc5be46e890ed9255e749806f46a88e26c commit 6d661cdc5be46e890ed9255e749806f46a88e26c Author: Alan Modra Date: Wed Oct 6 18:28:47 2021 +1030 PR28422, build_id use-after-free This fixes a bug in commit 5d9bbb73c1df. All fields preserved from a bfd in struct bfd_preserve need to be cleared in bfd_reinit. PR 28422 * format.c (bfd_reinit): Clear build_id. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28423] use-after-free in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28423 --- Comment #1 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=66468343379e535c6804a075709b5b49b09c6ed8 commit 66468343379e535c6804a075709b5b49b09c6ed8 Author: Alan Modra Date: Thu Oct 7 11:19:53 2021 +1030 PR28423, use-after-free in objdump XCOFF archives use a bi-directional linked list for file members. So one member points to both the previous member and the next member. Members may not be sequentially ordered in the file. This of course is over-engineered nonsense and an attractive target for fuzzers. (There is even a free list of members!) The testcase in PR28423 is an XCOFF archive with one member pointing to itself, which results in lots of bad behaviour. For example, "ar t" never terminates. The use-after-free with "objdump -r" happens like this: The first archive element is opened, its symbols are read and "canonicalized" for objdump, then relocations are read and printed. Those relocations use the canonicalized symbols, and also happen to be cached by the coff bfd backend support. objdump frees the symbols. The next archive element is then opened. This must be done before the first element is closed, because finding the next element uses data held in the currect element. Unfortunately the next element happens to be the original, so we aren't opening, we're reopening a bfd which has cached data. When the relocations are printed they use the cached copy containing references to the freed canonical symbols. This patch adds a little sanity checking to the XCOFF "open next archive file" support, so that it rejects archive members pointing at themselves. That is sufficient to cure this problem. Anything more is overkill. If someone deliberately fuzzes an XCOFF archive with an element loop then reports an "ar" bug when it runs forever, they will find their bug report closed WONTFIX. PR 28423 * coff-rs6000.c (_bfd_xcoff_read_ar_hdr): Save size occupied by member name in areltdata.extra_size. (_bfd_xcoff_openr_next_archived_file): Sanity check nextoff. * coff64-rs6000.c (xcoff64_openr_next_archived_file): Call _bfd_xcoff_openr_next_archived_file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28422] use-after-free in objdump at get_build_id (./bfd/opncls.c:1864)
https://sourceware.org/bugzilla/show_bug.cgi?id=28422 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The binutils-2_37-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c20c7adbeaa3af18a58ba1e20e6c33e7186356e3 commit c20c7adbeaa3af18a58ba1e20e6c33e7186356e3 Author: Alan Modra Date: Wed Oct 6 18:28:47 2021 +1030 PR28422, build_id use-after-free This fixes a bug in commit 5d9bbb73c1df. All fields preserved from a bfd in struct bfd_preserve need to be cleared in bfd_reinit. PR 28422 * format.c (bfd_reinit): Clear build_id. (cherry picked from commit 6d661cdc5be46e890ed9255e749806f46a88e26c) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28422] use-after-free in objdump at get_build_id (./bfd/opncls.c:1864)
https://sourceware.org/bugzilla/show_bug.cgi?id=28422 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The binutils-2_36-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a281816c8aeb12619d34eec8959a43dfa5c6b4ec commit a281816c8aeb12619d34eec8959a43dfa5c6b4ec Author: Alan Modra Date: Wed Oct 6 18:28:47 2021 +1030 PR28422, build_id use-after-free This fixes a bug in commit 5d9bbb73c1df. All fields preserved from a bfd in struct bfd_preserve need to be cleared in bfd_reinit. PR 28422 * format.c (bfd_reinit): Clear build_id. (cherry picked from commit 6d661cdc5be46e890ed9255e749806f46a88e26c) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28422] use-after-free in objdump at get_build_id (./bfd/opncls.c:1864)
https://sourceware.org/bugzilla/show_bug.cgi?id=28422 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |2.38 Resolution|--- |FIXED --- Comment #4 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28423] use-after-free in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28423 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.38 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28420] segv in objdump at disassemble_bytes objdump.c:3059
https://sourceware.org/bugzilla/show_bug.cgi?id=28420 --- Comment #4 from Alan Modra --- *** Bug 28414 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28410] Prevent region check failures when relaxation is not final
https://sourceware.org/bugzilla/show_bug.cgi?id=28410 --- Comment #7 from Nelson Chu --- > only restart the relax passes themselves. The purpose of `again` is used to rerun the relax passes themselves. That means once the `again` is always false for all input sections, and we decide to enter the next relax pass, then we don't have any obvious method that can move forward and rerun the previous relax passes. So that's what the commit ebdcad did, try to restart the relax passes without changing generic code, but it causes the region check problem that you mentioned. > However I do need to understand the original motivation for > restarting the set of relax passes The root cause is that I separate the pcgp relaxations from the relax pass 0 to a new relax pass. Why I separate the pcgp relaxations was mentioned in the commit abd20c, and that's why I had suggest that we probably shouldn't separate them to a new relax pass, we should try to modify the pcgp tables when relaxing. This is the option 3. > I was thinking more about option 2. If I were to rewrite the system of > restarting the whole set of relax passes without modifying `again` it should > solve this bug. If you have any idea for option 2 that won't change the generic code, then that's also a choice, welcome to share it and we are listening. There may be a way, but we have to clarify some issues, 1. I prefer to keep the current `again' mechanism, and don't change the info->relax_pass in the _bfd_riscv_relax_section. In the lang_relax_sections, we can only run `link_info.relax_pass` times at most, and use `again` to rerun the relax passes themselves, so only changing the info->relax_pass in the _bfd_riscv_relax_section will not solve the problem. 2. So I thought of a way before - we can just rerun the relax passes 0 itself, but we separate the relaxations to many sub relax passes by a target variable riscv_relax_pass in the riscv_elf_link_hash_table. For example, we do the lui/call relaxations when riscv_relax_pass is 0, and we do the pcgp relaxations when riscv_relax_pass is 1. We can set the `again` to true when we are rerunning the riscv_relax_pass 0->1->0->1->0->..., and in fact we are still in the loop of relax pass 0. But the problem is that - How do we know when to change the riscv_relax_pass in the _bfd_riscv_relax_section, without modifying generic code? Perhaps we could run an extra relax pass at first, and then record the first and last input sections. So that we can restart the riscv_relax_pass when the input section is the last one we have recorded. But I'm not sure if recording the first and last sections of a relax round is a good idea or not. However, if you have any good idea for the option 2, please feels free to try it. Just that we should try our best that don't modify any generic code. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28414] SEGV in objdump at bfd/reloc.c:8423
https://sourceware.org/bugzilla/show_bug.cgi?id=28414 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #1 from Alan Modra --- Seems to be fixed *** This bug has been marked as a duplicate of bug 28420 *** -- You are receiving this mail because: You are on the CC list for the bug.
