[Bug binutils/26907] objcopy gives memsiz to segment containing empty SHT_NOBITS section
https://sourceware.org/bugzilla/show_bug.cgi?id=26907 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com Last reconfirmed||2020-11-27 --- Comment #2 from Alan Modra --- It's not just the objcopy going wrong here. ld shouldn't be creating two PT_LOAD headers where one would suffice. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 --- Comment #4 from katayama.hirofumi.mz at gmail dot com --- Reproduction steps: $ which cpp /mingw32/bin/cpp $ cp /mingw32/bin/cpp "/mingw32/bin/cpp .exe" $ windres "--preprocessor=/mingw32/bin/cpp .exe" a.rc cpp: error: .exe: No such file or directory cpp: fatal error: no input files compilation terminated. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865
--- Comment #3 from katayama.hirofumi.mz at gmail dot com ---
Not fixed yet. Compilation error.
resrc.c: In function 'filename_need_quotes':
resrc.c:368:9: error: duplicate case value
368 | case ' ':
| ^~~~
resrc.c:363:9: note: previously used here
363 | case ' ':
switch (*filename)
{
case '&':
case ' ': // this
case '<':
case '>':
case '|':
case '%':
case ' ': // and this
return 1;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/24718] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak
https://sourceware.org/bugzilla/show_bug.cgi?id=24718 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 --- Comment #2 from Rich Felker --- It's not that smart_rename should open it and use fchown+fchmod on the result; indeed as you figured that has the same race. The problem is that you threw away the only safe way to perform modifications on the temp file you just created: the fd returned by mkstemp. In addition to the source and dest names, smart_rename needs to take the already-open file descriptors for source and dest that were used for the objcopy (or whatever) operation. Note: I missed this in the original report, but it's also important to use fstat on the file that will be replaced, rather than lstat on the pathname, to ensure the permissions that will be set on the new file are the ones of the file that was processed, and not some other file that was substituted in its place. Failure to do this right may not be exploitable, since the hard link count is checked, but it's still possibly erroneous. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Last reconfirmed||2020-11-26 CC||nickc at redhat dot com Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Nick Clifton --- Hi Katayama, Please could you try out the uploaded patch and let me know if it works. It turns out that there is already a mechanism for quoting the filename, (see how the fnquotes variable is initialised), but it was not allowing for filenames that contain spaces. The patch tries to fix this. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 --- Comment #2 from Nick Clifton --- Created attachment 12999 --> https://sourceware.org/bugzilla/attachment.cgi?id=12999=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Last reconfirmed||2020-11-26 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Nick Clifton --- Hi Rich, > At least objcopy and perhaps other utilities generate a temp file safely > with mkstemp then rename it to atomically replace the original, but the > smart_rename function (binutils/rename.c) used to do this then performs > chown and chmod on the target pathname rather than fchown/fchmod on the > file. This is subject to all the classic symlink race attacks and can be > used to get root to chown or chmod arbitrary files. In a worst case, with > multiple racing file replacements, it can be used to chmod arbitrary > root-owned files suid. Not being a security expert, please can I check a couple of things with you: The code in smart_rename() has already checked that the destination file is not a symbolic link, so presumably the vulnerability occurs if the attacker is able to replace the destination file after the rename has happened but before the chmod() and/or chown() happen, right ? So in order to protect the destination file it needs to be opened first and then fchown/fchmod can be used. Bit isn't there still a period of vulnerability between the call to rename() and the call to fopen() ? Or is there a way to rename a file and open it at the same time ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26946] [nm] memory allocation failed
https://sourceware.org/bugzilla/show_bug.cgi?id=26946 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Hao, Thanks for reporting this problem. I have now checked in a patch to fix the BFD library, so that it will now issue this warning: nm: DWARF error: section .debug_abbrev is larger than its filesize! (0xff040b vs 0xaf58) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26946] [nm] memory allocation failed
https://sourceware.org/bugzilla/show_bug.cgi?id=26946 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=647cebce12a6b0a26960220caff96ff38978cf24 commit 647cebce12a6b0a26960220caff96ff38978cf24 Author: Nick Clifton Date: Thu Nov 26 17:08:33 2020 + Prevent a memory allocation failure when parsing corrupt DWARF debug sections. PR 26946 * dwarf2.c (read_section): Check for debug sections with excessive sizes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 Siddhesh Poyarekar changed: What|Removed |Added Flags||security+ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26946] [nm] memory allocation failed
https://sourceware.org/bugzilla/show_bug.cgi?id=26946 Nick Clifton changed: What|Removed |Added Last reconfirmed||2020-11-26 Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26936] ld drops relocation for .text.__x86.get_pc_thunk.bx
https://sourceware.org/bugzilla/show_bug.cgi?id=26936 --- Comment #22 from Michael Matz --- (In reply to Fangrui Song from comment #20) > (I thought that .gnu.linkonce was deprecated almost 20 years ago and we > should phase out linkonce instead of adding more compatibility code...) Deprecation != not used anymore in the wild. In this case it's crt files compiled with options intentionally emitting linkonce, not comdat, sections, also for compatibility. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26936] ld drops relocation for .text.__x86.get_pc_thunk.bx
https://sourceware.org/bugzilla/show_bug.cgi?id=26936 --- Comment #21 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=9ed0136bff648c2f32d7462d3ab9205b61778837 commit 9ed0136bff648c2f32d7462d3ab9205b61778837 Author: Alan Modra Date: Thu Nov 26 17:45:26 2020 +1030 PR26936 testsuite fixes Many targets fail this test due to -z noseparate-code not being supported, or _start not being the proper entry symbol, or "as -g" something other than "generate debug". PR 26936 * testsuite/ld-elf/pr26936.d: Pass --gen-debug to gas rather than -g. Only run when -shared -z options are supported. * testsuite/ld-elf/pr26936b.s: Define more entry symbols. -- You are receiving this mail because: You are on the CC list for the bug.
