[Bug binutils/25078] stack overflow in function find_abstract_instance
https://sourceware.org/bugzilla/show_bug.cgi?id=25078 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #5 from Nick Clifton --- (In reply to Trupti Pardeshi from comment #4) Hi Trupti, > May I know if Binutils-2.31 is also affected and requires this fix? Yes. The 2.32 and 2.33 releases (and branches) are also affected too. Currently the fix is only in the mainline development sources. 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/25078] stack overflow in function find_abstract_instance
https://sourceware.org/bugzilla/show_bug.cgi?id=25078 --- Comment #6 from Trupti Pardeshi --- (In reply to Nick Clifton from comment #5) > (In reply to Trupti Pardeshi from comment #4) > Hi Trupti, > > > May I know if Binutils-2.31 is also affected and requires this fix? > > Yes. The 2.32 and 2.33 releases (and branches) are also affected too. > Currently the fix is only in the mainline development sources. > > Cheers > Nick Thank you so much Nick for the clarification. Appreciate your reply for mentioning 2.33 version as well. Thanks. -- 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/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #8 from Nick Alcock --- Nice diagnosis! Looks like there are some bugs in busybox and tcc to fix. I agree that the first three things you reported are bugs, and I'll fix them once I get a spare moment. Thanks for the report! -- 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/25070] SEGV in function _bfd_dwarf2_find_nearest_line
https://sourceware.org/bugzilla/show_bug.cgi?id=25070 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #6 from Nick Clifton --- (In reply to Trupti Pardeshi from comment #5) Hi Trupti, > May I know if Binutils-2.31 is also affected and requires this fix? Any > heads up will be appreciated. Yes. The 2.32 and 2.33 releases (and branches) are also vulnerable to this problem. Only the mainline development sources are currently fixed. 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/25070] SEGV in function _bfd_dwarf2_find_nearest_line
https://sourceware.org/bugzilla/show_bug.cgi?id=25070 --- Comment #7 from Trupti Pardeshi --- (In reply to Nick Clifton from comment #6) > (In reply to Trupti Pardeshi from comment #5) > Hi Trupti, > > > May I know if Binutils-2.31 is also affected and requires this fix? Any > > heads up will be appreciated. > > Yes. The 2.32 and 2.33 releases (and branches) are also vulnerable to > this problem. Only the mainline development sources are currently fixed. > > Cheers > Nick Thank you so much Nick for the clarification. Appreciate your reply for mentioning 2.33 version as well. Thanks. -- 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
Fyi: this list, bug-binutils, just had it's subject [tag] and footer removed
The Free Software Foundation has changed the GNU Mailman settings on this list. The short version is that any subject prefix or message footer has been removed, allowing us to turn off DMARC from munging. Any list administrator for this list is free to change these settings back, instructions are below. The change is to better deal with increased adoption of the DMARC email standard. The default Mailman settings were causing messages sent from users with strict DMARC policy domains like yahoo.com to be rejected when sent to list subscribers by Mailman. See the end of this email for a technical overview of DMARC and DKIM. There are two main ways to fix the issue by changing Mailman list settings. The first option, and the preferable way for discussion lists, is what we call the "unmodified message fix." There are Mailman list settings which modify the messages by adding a subject prefix (e.g. [list-name]) or a footer. Modifying the message breaks DKIM message signatures and thus DMARC, so we just turn those off. Many lists are already this way and there is no change for them. Instead of using the subject prefix to identify a list, subscribers should use the List-Id, To, and Cc headers. List footer information can also be be put in the welcome email to subscribers and the list information page by list administrators. We changed the default for new lists to send unmodified messages, and are now updating existing discussion lists to the new default. We emailed all list administrators and moderators and Savannah group admins to allow them to opt in to the alternate fix before we made this change. However, not all lists had a valid administrator contact. The second option is for lists which want or need to continue to modify the message, for example with subject prefix or footer settings. In this case we turn on a Mailman list setting called dmarc_moderation_action: "Munge From". With this, if a strict DMARC sender sends to the list, we alter the headers of that message like so: A message sent to the list: From: Anne Example Person Is modified by Mailman and sent to subscribers as: From: Anne Example Person via Alist Reply-To: Anne Example Person Without going into all of the details, here's a few points about why we concluded the unmodified message fix is better for discussion lists. Email clients don't all treat munged messages the same way as unmunged, and humans read these headers so it can confuse people, causing messages not to be sent to the expected recipients. GNU Mailman has an option to do "Munge From" always, but does not recommend using it[1]. While we're not bound by what others do, it's worth noting that other very large free software communities like Debian GNU/Linux have adopted the unmodified message fix[2]. The unmodified messages fix avoids breaking DKIM cryptographic signatures, which show the message was authorized by the signing domain and seems like a generally good security practice. Tools to manage patches, for example patchew, use the from field and are tripped up by from munging. For any Mailman list administrator who wants to change or look over the relevant settings: The dmarc_moderation_action setting is under "Privacy Options" subsection "Sender Filters". The only options that should be selected are "Accept" or "Munge From", along with corresponding changes to the subject_prefix option under "General Options", and msg_footer is under "Non-digest options". If no list administrators or moderators are around for this list, anyone should feel free to try to track them down or figure out who should become one and explain in detail by replying to sysad...@gnu.org. Please be patient, this process may take several weeks. Please send any questions that should be public to mail...@gnu.org. For private ones, just reply to sysad...@gnu.org. For the general announcement of these changes, please read https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html and https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html A short DMARC technical overview: DMARC policy is a DNS txt record at a _dmarc subdomain. For example: $ host -t txt _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:address@hidden;";; The only important thing there for our purpose is p=reject. p=reject means that conforming mail servers that receive mail with a from header of *@yahoo.com will reject that email unless it was either 1. sent from Yahoo's email servers, or 2. its DKIM signature is verified. A DKIM signature[5] is a public key cryptographic signature of the email body and some headers included in the message header "DKIM-Signature". A verified DKIM signature means that email body and signed headers have not been modified. Comprehensive resources about DMARC tend to downplay or ignore its problems, but some that have helped me are Wikipedia[6], the Mailman wiki[1], dmarc.org wiki[7], and the DMARC rfc[8]. [
[Bug binutils/4499] assign file positions assumes segment offsets increasing
https://sourceware.org/bugzilla/show_bug.cgi?id=4499 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sources dot redhat.c |amodra at gmail dot com |om | Target Milestone|--- |2.34 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/4499] assign file positions assumes segment offsets increasing
https://sourceware.org/bugzilla/show_bug.cgi?id=4499 --- Comment #4 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=30fe183248b2523ecff9da36853e2f893c4c4b91 commit 30fe183248b2523ecff9da36853e2f893c4c4b91 Author: Alan Modra Date: Wed Oct 23 17:40:51 2019 +1030 PR4499, assign file positions assumes segment offsets increasing This rewrites much of assign_file_positions_for_non_load_sections to allow objcopy and strip to handle cases like that in PR4499 where program headers were not in their usual position immediately after the ELF file header, and PT_LOAD headers were not sorted by paddr. PR 4499 include/ * elf/internal.h (struct elf_segment_map): Delete header_size. Add no_sort_lma and idx. bfd/ * elf-nacl.c (nacl_modify_segment_map): Set no_sort_lma for all PT_LOAD segments. * elf32-spu.c (spu_elf_modify_segment_map): Likewise on overlay PT_LOAD segments. * elf.c (elf_sort_segments): New function. (assign_file_positions_except_relocs): Use shortcuts to elfheader and elf_tdata. Seek to e_phoff not sizeof_ehdr to write program headers. Move PT_PHDR check.. (assign_file_positions_for_non_load_sections): ..and code setting PT_PHDR p_vaddr and p_paddr, and code setting __ehdr_start value.. (assign_file_positions_for_load_sections): ..to here. Sort PT_LOAD headers. Delete header_pad code. Use actual number of headers rather than allocated in calculating size for program headers. Don't assume program headers follow ELF file header. Simplify pt_load_count code. Only set "off" for PT_LOAD or PT_NOTE in cores. (rewrite_elf_program_header): Set p_vaddr_offset for segments that include file and program headers. (copy_elf_program_header): Likewise, replacing header_size code. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/4499] assign file positions assumes segment offsets increasing
https://sourceware.org/bugzilla/show_bug.cgi?id=4499 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Alan Modra --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
