[Bug gas/12240] offset can't be used as label in Intel syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=12240 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #2 from LIU Hao --- Is https://sourceware.org/bugzilla/show_bug.cgi?id=30336 a dup of this? -- You are receiving this mail because: You are on the CC list for the bug.
Re: Stack BufferOverflow in readelf.c
On Apr 27 2023, 2ourc3 1er wrote: > The function includes a declaration of a fixed-sized buffer, *char > name_buf[40];*, which is used later in the function with the *sprintf* > function:* sprintf* (*name_buf*, "", > (unsigned int) *psym->st_shndx*); > > The problem with this implementation is that the st_shndx argument used in > sprintf is controlled by the user, and therefore, could be larger than the > size of the buffer, leading to a Stack BufferOverflow on the buffer > *name_buf.* That is obviously impossible: psym->st_shndx can be at most 65535, so it cannot be larger than 4 characters when formatted as a hexadecimal number. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Stack BufferOverflow in readelf.c
Dears, I am writing to bring to your attention a potential issue in the function *dump_relocations *in the software* readelf.c.* The function includes a declaration of a fixed-sized buffer, *char name_buf[40];*, which is used later in the function with the *sprintf* function:* sprintf* (*name_buf*, "", (unsigned int) *psym->st_shndx*); The problem with this implementation is that the st_shndx argument used in sprintf is controlled by the user, and therefore, could be larger than the size of the buffer, leading to a Stack BufferOverflow on the buffer *name_buf.* To prevent potential security vulnerabilities, I recommend modifying the implementation to use a dynamic buffer allocation that adjusts its size according to the length of the input argument. Otherwise, the function sprintf and snprintf allows to specify a maximum input size. This would ensure that the buffer can accommodate all possible input values, mitigating the risk of a BufferOverflow. Please let me know if you have any questions or concerns regarding this issue. Best regards, s0urc3
[Bug gas/30336] The GNU Assembler has bugs in Intel syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=30336 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #1 from LIU Hao --- Also this: ``` E:\lh_mouse\Desktop>as --version GNU assembler (GNU Binutils) 2.40 Copyright (C) 2023 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-w64-mingw32'. E:\lh_mouse\Desktop>cat test.s .intel_syntax noprefix mov eax, dword ptr shr[rip] E:\lh_mouse\Desktop>as test.s test.s: Assembler messages: test.s:2: Error: invalid use of operator "shr" ``` GCC generates `mov eax, dword ptr shr[rip]` and Clang generates `mov eax, dword ptr [rip + shr]`, but AS accepts neither. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd
https://sourceware.org/bugzilla/show_bug.cgi?id=30358 Michael Matz changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Michael Matz --- Fixed in master. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd
https://sourceware.org/bugzilla/show_bug.cgi?id=30358 --- Comment #13 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Michael Matz : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=670c91c0c5eb3fb16d42fe5b2d48a33c64e3ec52 commit 670c91c0c5eb3fb16d42fe5b2d48a33c64e3ec52 Author: Michael Matz Date: Tue Apr 25 17:10:05 2023 +0200 Fix PR30358, performance with --sort-section since af31506c we only use the binary tree when section sorting is required. While its unbalanced and hence can degrade to a linear list it should otherwise have been equivalent to the old code relying on insertion sort. Unfortunately it was not. The old code directly used lang_add_section to populate the sorted list, the new code first populates the tree and only then does lang_add_section on the sorted result. In the testcase we have very many linkonce section groups, and hence lang_add_section won't actually insert anything for most of them. That limited the to-be-sorted list length previously. The tree-sorting code OTOH first created a tree of all candidates sections, including those that wouldn't be inserted by lang_add_section, hence increasing the size of the sorting problem. In the testcase the chain length went from about 1500 to 106000, and in the degenerated case (as in the testcase) that goes in quadratically. This splits out most of the early-out code from lang_add_section to its own function and uses the latter to avoid inserting into the tree. This refactoring slightly changes the order of early-out tests (the ones based on section flags is now done last, and only in lang_add_section). The new function is not a pure predicate: it can give warnings and it might change output_section, like the old early-out code did. I have also added a skip-warning case in the first discard case, whose non-existence seemed to have been an oversight. PR 30358 * ldlang.c (wont_add_section_p): Split out from ... (lang_add_section): ... here. (output_section_callback_sort): Use wont_add_section_p to not always add sections to the sort tree. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/16566] Please provide a way to include static symbols in linker map file
https://sourceware.org/bugzilla/show_bug.cgi?id=16566 --- Comment #4 from Nick Clifton --- (In reply to jon from comment #3) > Is there perhaps anyway to optionally filter out labels generated within > functions (E.g. those normally declared beginning with L or .L that are the > targets of branch instructions)? Actually yes. :-) There is a function is_local_label() in the BFD library which does exactly that. I will add it to my patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/16566] Please provide a way to include static symbols in linker map file
https://sourceware.org/bugzilla/show_bug.cgi?id=16566 --- Comment #3 from jon at beniston dot com --- Thanks Nick, I see local data and functions now. Is there perhaps anyway to optionally filter out labels generated within functions (E.g. those normally declared beginning with L or .L that are the targets of branch instructions)? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/16566] Please provide a way to include static symbols in linker map file
https://sourceware.org/bugzilla/show_bug.cgi?id=16566 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|NEW |ASSIGNED --- Comment #2 from Nick Clifton --- Created attachment 14853 --> https://sourceware.org/bugzilla/attachment.cgi?id=14853=edit Proposed patch Hi Paul, Hi Jon, Would either of you like to try out this potential patch ? It adds local symbols to the linker map at the appropriate places, with a prefix of "(local) " so that they can be quickly identified. (Note local symbols are displayed after global symbols for a given section, rather than being mixed in with the global symbols). It is not complete yet. I think that I am going to have to add a command line option to control its use, as I expect that there are people out there who rely on the current format not changing. Plus I will need to add a testcase or two to the testsuite. I did find that *some* local symbols are already included in the linker map, eg _GLOBAL_OFFSET_TABLE_ and at the moment such symbols will appear twice. So I ought to try to find a way to stop that from happening as well. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
