[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #4 from Fangrui Song --- Perhaps GNU ld can split `-z separate-code` into two options `--rosegment` and `-z separate-code`? I have some description at https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#no-rosegment > Separating data and code is a best practice. Therefore lld defaults to --rosegment while it defauls to `-z noseparate-code` to avoid waste. File content at the boundary of R/RX can be double mapped, which technically can be used to find ROP gadgets. However, decreasing ROP gadgets there is pretty much a secure theatre. https://isopenbsdsecu.re/mitigations/rop_removal/ is somewhat related. > But I wonder that why the alignment is not the kernel PAGESIZE(I set > PAGE_SIZE to 4096 when compiling, but the alignment is still 65535)? The protocol between the linke and the kernel is that a linked object file may run on systems with different page sizes. All page sizes not larger than MAXPAGESIZE (link-time decision) are supported. The model in practice does not build a different object file for each page size. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 63085 in oss-fuzz: binutils:fuzz_disassemble: Abrt in get_field_imm5
Updates: Labels: -restrict-view-commit Comment #3 on issue 63085 by sheriffbot: binutils:fuzz_disassemble: Abrt in get_field_imm5 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=63085#c3 This bug has been fixed. 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 binutils/30949] New: A potential bug of null pointer dereference
https://sourceware.org/bugzilla/show_bug.cgi?id=30949 Bug ID: 30949 Summary: A potential bug of null pointer dereference Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: a860641231 at 163 dot com Target Milestone: --- Created attachment 15157 --> https://sourceware.org/bugzilla/attachment.cgi?id=15157&action=edit contain image describing the source code of potentical npd Hi, I found a potential null pointer dereference bug in the binutils project source code of bfd, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the reason that generate the bug, that is , variable isec receives the return value from function bfd_section_from_elf_index(which may be null value) and is dereferenced at line 12973 without checking isec is null or not. In another call site(elf64-ppc.c), as in many others, variable sec receives the return value from function bfd_section_from_elf_index ,and check sec is null or not before deference of variable sec. Although the code shown is for version 2.32 but this potential bug is still exist in the current version. would you can help to check if this bug is true? thank you for your effort and patience! -- You are receiving this mail because: You are on the CC list for the bug.
