[Bug ld/26936] ld drops relocation for .text.__x86.get_pc_thunk.bx
https://sourceware.org/bugzilla/show_bug.cgi?id=26936 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.36 Status|UNCONFIRMED |NEW Summary|[ld, PIE] ld drops |ld drops relocation for |relocation for |.text.__x86.get_pc_thunk.bx |.text.__x86.get_pc_thunk.bx | Ever confirmed|0 |1 Last reconfirmed|2020-11-24 00:00:00 |2020-11-25 --- Comment #16 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2020-November/114281.html -- 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 #17 from Michael Matz --- (In reply to H.J. Lu from comment #15) > My /lib/crti.o has > > COMDAT group section [1] `.group' [__x86.get_pc_thunk.bx] contains 1 > sections: >[Index]Name >[8] .text.__x86.get_pc_thunk.bx Sure, which is why I have provided sources. We have to support old systems with oldish glibc, and that has linkonce sections in those files. Thanks for the patch, it works. But I think you want to check kept != NULL before going into the loop. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/26937] [gold, PIE] ld drops relocations for .text.__x86.get_pc_thunk.bx
https://sourceware.org/bugzilla/show_bug.cgi?id=26937 --- Comment #1 from H.J. Lu --- Gold doesn't handle comdat section correctly for debug sections. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/26937] [gold, PIE] ld drops relocations for .text.__x86.get_pc_thunk.bx
https://sourceware.org/bugzilla/show_bug.cgi?id=26937 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.36 --- Comment #2 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2020-November/114284.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] New: Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 Bug ID: 26945 Summary: Unsafe chown+chmod in smart_rename, possibly elsewhere Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- 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. This is only an issue if the file being operated on is in a directory writable by the attacker. However, the whole point of the ownership/permissions restoration logic seems to be for the case where root is operating on other users' files, and it seems likely that the directory will also be user-owned. I'm reporting this through public issue rather than security because I don't think there are direct ways to exploit it programmatically in a normal environment. There may be when the affected tools are used in automated scripts acting on user-owned files, though. -- 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 Rich Felker changed: What|Removed |Added CC||siddhesh at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26946] New: [nm] memory allocation failed
https://sourceware.org/bugzilla/show_bug.cgi?id=26946 Bug ID: 26946 Summary: [nm] memory allocation failed Product: binutils Version: 2.35.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hao-wang20 at mails dot tsinghua.edu.cn Target Milestone: --- Created attachment 12997 --> https://sourceware.org/bugzilla/attachment.cgi?id=12997&action=edit asan-memory-allocation-failed Hello, I found a crash in nm-new when doing fuzzing experiments. And it can be reproduced in the master branch. I downloaded source code from git, and I built it with Ubuntu 18.04 with gcc 7.5.0 with ASAN, and the following command to build nm-new from the source: CFLAGS="-O1 -fsanitize=address -g" ./configure; make clean all; You can reproduce the crash with the following command: nm-new -l The AddressSanitizer message of the crash is: ==48823==ERROR: AddressSanitizer failed to allocate 0xff3000 (1095216672768) bytes of LargeMmapAllocator (error code: 12) ==48823==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_common.cc:118 "((0 && "unable to mmap")) != (0)" (0x0, 0x0) #0 0x7f78c8f8abf2 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe9bf2) #1 0x7f78c8fa9575 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x108575) #2 0x7f78c8f94482 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xf3482) #3 0x7f78c8fa0895 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xff895) #4 0x7f78c8ec97fd (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x287fd) #5 0x7f78c8f7fb0a in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb0a) #6 0x55fe62a75ec7 in bfd_malloc /home/vul337/programs/psrc/binutils_bk/bfd/libbfd.c:275 #7 0x55fe62cbddeb in read_section dwarf2.c:566 #8 0x55fe62ccfae8 in decode_line_info dwarf2.c:2129 #9 0x55fe62ceb516 in comp_unit_maybe_decode_line_info dwarf2.c:3938 #10 0x55fe62ceb516 in comp_unit_find_line dwarf2.c:3972 #11 0x55fe62cf19bf in _bfd_dwarf2_find_nearest_line dwarf2.c:5100 #12 0x55fe62bb81f2 in _bfd_elf_find_line /home/vul337/programs/psrc/binutils_bk/bfd/elf.c:9212 #13 0x55fe62a1fcfe in print_symbol /home/vul337/programs/psrc/binutils_bk/binutils/nm.c:1031 #14 0x55fe62a23640 in print_symbols /home/vul337/programs/psrc/binutils_bk/binutils/nm.c:1112 #15 0x55fe62a23640 in display_rel_file /home/vul337/programs/psrc/binutils_bk/binutils/nm.c:1236 #16 0x55fe62a261d3 in display_file /home/vul337/programs/psrc/binutils_bk/binutils/nm.c:1403 #17 0x55fe62a1b237 in main /home/vul337/programs/psrc/binutils_bk/binutils/nm.c:1891 #18 0x7f78c88cdbf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6) #19 0x55fe62a1d3c9 in _start (/home/vul337/programs/nm_master/nm-new+0xad3c9) -- You are receiving this mail because: You are on the CC list for the bug.
Issue 26635 in oss-fuzz: binutils:fuzz_bfd: Heap-buffer-overflow in _bfd_vms_save_sized_string
Updates: Labels: -restrict-view-commit Comment #3 on issue 26635 by sheriffbot: binutils:fuzz_bfd: Heap-buffer-overflow in _bfd_vms_save_sized_string https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26635#c3 This bug has been fixed for 30 days. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug libctf/26934] [2.36 Regression] ctf-dump.c:406:4: error: format not a string literal and no format arguments [-Werror=format-security]
https://sourceware.org/bugzilla/show_bug.cgi?id=26934 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Alcock : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e8cda2090524b6a129fe40f62397976141c1e12e commit e8cda2090524b6a129fe40f62397976141c1e12e Author: H.J. Lu Date: Tue Nov 24 14:08:43 2020 + libctf: Pass format argument to asprintf libctf/ChangeLog 2020-09-23 H.J. Lu PR libctf/26934 * ctf-dump.c (ctf_dump_objts): Pass format argument to asprintf. -- 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 #18 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=58349d00f461904f20dae88d48c1fda11cbb47bc commit 58349d00f461904f20dae88d48c1fda11cbb47bc Author: H.J. Lu Date: Wed Nov 25 16:14:13 2020 -0800 elf: Get the real kept section When mixing linkonce and comdat sections, we need to keep searching to get the real kept section. bfd/ PR ld/26936 * elflink.c (_bfd_elf_check_kept_section): Get the real kept section. ld/ PR ld/26936 * testsuite/ld-elf/pr26936.d: New file. * testsuite/ld-elf/pr26936a.s: Likewise. * testsuite/ld-elf/pr26936b.s: Likewise. * testsuite/ld-elf/pr26936c.s: Likewise. -- 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 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from H.J. Lu --- Fixed for 2.36. -- 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 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #20 from Fangrui Song --- (I thought that .gnu.linkonce was deprecated almost 20 years ago and we should phase out linkonce instead of adding more compatibility code...) -- You are receiving this mail because: You are on the CC list for the bug.
