[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #3 from Evgeny Vereshchagin --- As far as I can see with the fuzz branch rebased on top on my fuzzing branch almost all the issues including https://sourceware.org/pipermail/elfutils-devel/2021q4/004596.html are gone. Thanks! I'll attach files triggering the remaining issues shortly: ``` $ UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1 LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core SIGABRT.PC.7fffe4f4e84c.STACK.18f0f46b60.CODE.-6.ADDR.0.INSTR.mov%eax,%ebp.fuzz link_map.c:1040:20: runtime error: variable length array bound evaluates to non-positive value 0 #0 0x7fbc58f053e9 in dwfl_link_map_report /home/vagrant/elfutils/libdwfl/link_map.c:1040 #1 0x7fbc59023fa7 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:552 #2 0x4053f7 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #3 0x7fbc581d9471 in argp_parse (/lib64/libc.so.6+0x11e471) #4 0x404b39 in main /home/vagrant/elfutils/src/stack.c:695 #5 0x7fbc580e855f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f) #6 0x7fbc580e860b in __libc_start_main_impl (/lib64/libc.so.6+0x2d60b) #7 0x404fa4 in _start (/home/vagrant/elfutils/src/stack+0x404fa4) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior link_map.c:1040:20 in ``` ``` $ UBSAN_OPTIONS=print_stacktrace=1:print_summary=1:halt_on_error=1 LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core SIGABRT.PC.7fffe4f4e84c.STACK.1976b2f3ff.CODE.-6.ADDR.0.INSTR.mov%eax,%ebp.fuzz gelf_xlate.h:48:1: runtime error: member access within misaligned address 0x7f0817719077 for type 'struct Elf32_Dyn', which requires 4 byte alignment 0x7f0817719077: note: pointer points here 00 10 00 00 00 00 00 00 00 00 02 01 00 00 00 00 00 00 7f 45 46 4c 46 00 00 01 01 00 01 00 08 00 ^ #0 0x7f0822689542 in Elf32_cvt_Dyn /home/vagrant/elfutils/libelf/gelf_xlate.h:48 #1 0x7f082268835e in elf32_xlatetom /home/vagrant/elfutils/libelf/elf32_xlatetom.c:104 #2 0x7f0819563307 in dwfl_segment_report_module /home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:848 #3 0x7f081956c06c in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:563 #4 0x4053f7 in parse_opt /home/vagrant/elfutils/src/stack.c:595 #5 0x7f0818721471 in argp_parse (/lib64/libc.so.6+0x11e471) #6 0x404b39 in main /home/vagrant/elfutils/src/stack.c:695 #7 0x7f081863055f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f) #8 0x7f081863060b in __libc_start_main_impl (/lib64/libc.so.6+0x2d60b) #9 0x404fa4 in _start (/home/vagrant/elfutils/src/stack+0x404fa4) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gelf_xlate.h:48:1 in ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #4 from Evgeny Vereshchagin --- Created attachment 13874 --> https://sourceware.org/bugzilla/attachment.cgi?id=13874&action=edit File triggering "variable length array bound evaluates to non-positive value 0" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #5 from Evgeny Vereshchagin --- Created attachment 13875 --> https://sourceware.org/bugzilla/attachment.cgi?id=13875&action=edit File triggering "member access within misaligned address" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28720] UBSan: member access within misaligned address 0x7f6e8d80f142 for type 'struct Elf32_Phdr', which requires 4 byte alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=28720 --- Comment #6 from Evgeny Vereshchagin --- (In reply to Mark Wielaard from comment #2) > Interesting. I did run afl for some time (more than a day) and it found some > more issues, but none of these (yet?). I'll try honggfuzz in the future to > see if it can find some more. > FWIW https://sourceware.org/pipermail/elfutils-devel/2021q4/004584.html should make it much more easier to use honggfuzz. It's safe to say that it was battle-tested in the sense that it's compatible with gcc, clang, ASan, UBsan and so on. Something like `make check V=1 VERBOSE=1 TESTS=run-fuzz-dwfl-core.sh FUZZ_TIME=3600` allows running the fuzz target for an hour with honggfuzz (if elfutils is built with `--enable-honggfuzz`) -- You are receiving this mail because: You are on the CC list for the bug.
Cont.: Adding a new section to an ELF file aborts with Assertion `shdr != NULL'
Hi,
Sorry I for some reason could not reply to the original thread here to
follow up:
https://www.mail-archive.com/elfutils-devel@sourceware.org/msg04076.html
But I am facing the same issue, adding the section to a very simple ELF
file fails with Assertion `shdr != NULL'. I am new to this so I am sure I
am doing something wrong, but not exactly certain what it is. I have also
tried to open ELF with ELF_C_WRITE as opposed to ELF_C_RDWR but then my
error is "elf_newdata() failed: executable header not created first" so I
am not sure what the proper sequence of events would be to add a section.
Below is my code and a run with the message.
Thank you!
Elfutils 0.186-1 - Debian testing
= sample test.c I want to add a section to
=
#include
int main(int argc, char **argv){
printf("Hello world");
return 0;
}
=== test.c ELF Sections before adding section ===
(Intel x86-64)
Program header table entries: 11 (40 - 2A8)
0 P r--40 268 0040 6 D rw- 2DF8 1E0 3DF8
1 I "/lib64/ld-linux-x86-64.so.2" 7 N "GNU"
2 B r-- 0 568 8 U r-- 20103C 2010
3 B r-s 1000 1DD 1000 9 . rw- 0 0
4 B r-- 2000 158 2000 10 R r-- 2DE8 218 3DE8
5 B rw- 2DE8 248 3DE8 +8
Section header table entries: 30 (3728 - 3EA8)
0 (null) 15 B r-x 11D4 9 .fini
1 I "/lib64/ld-linux-x86-64.so.2" 16 B r-- 200010 .rodata
2 N "GNU" 17 U r-- 20103C .eh_frame_hdr
3 N "GNU" 18 U r-- 2050 108 .eh_frame
4 H r-- 30824 .gnu.hash [5] 19 ? rw- 2DE8 8 .init_array
5 S r-- 330A8 .dynsym [6]20 ? rw- 2DF0 8 .fini_array
6 $ r-- 3D884 .dynstr21 D rw- 2DF8 1E0 .dynamic [6]
7 V r-- 45C E .gnu.version [5] 22 O rw- 2FD828 .got
8 V r-- 47020 .gnu.version_r [6] 23 P rw- 300020 .got.plt
9 R r-- 490C0 .rela.dyn:0 [5]24 B rw- 302010 .data
10 R r-- 55018 .rela.plt:23 [5] 25 0 rw- 3030 8 .bss
11 B r-x 100017 .init 26 C "GCC: (Debian 11.2.0-10)
11.2.0"
12 P r-x 102020 .plt 27 S --- 3050 3C0 .symtab [28]
13 B r-x 1040 8 .plt.got 28 $ --- 3410 210 .strtab
14 B r-x 1050 181 .text 29 $ --- 3620 107 .shstrtab [S]
= add_section.c ===
int main(int argc, char **argv) {
// Parameters
char *bin_path = NULL;
char *data_file = NULL;
char *section_name = NULL;
// Elf section and data
unsigned char *section_data_raw = NULL; // Section Data buffer content
int fd = -1; // File descriptor for the ELF file
Elf *e = NULL; // ELF struct
Elf64_Addr sec_start_addr = 0; // Section Start Address
Elf64_Xword sec_sz = 0;// Section size
uint64_t sec_data_offset = 0; // Data Offset from start of section
size_t sec_data_sz = 0;// Date size
Elf_Scn *scn;
Elf_Data *data;
Elf64_Shdr *shdr;
size_t scn_idx;
off_t fsize = -1;
if (argc < 4) {
printf("secinject \n");
exit(EXIT_FAILURE);
}
if (check_bin_path(argv[1], &bin_path) == FALSE) {
err(EXIT_FAILURE, "RW Access to \"%s\" failed", argv[1]);
}
section_name = argv[2];
if (check_data_path(argv[3], &data_file) == FALSE) {
err(EXIT_FAILURE, "Read Access to \"%s\" failed", argv[3]);
}
ssize_t nread = read_file_to_buffer(data_file, §ion_data_raw);
if (elf_version(EV_CURRENT) == EV_NONE)
errx(EXIT_FAILURE, "ELF library initialization failed: %s",
elf_errmsg(-1));
// Open file rw
if ((fd = open(argv[1], O_RDWR, 0)) < 0)
err(EXIT_FAILURE, "open \"%s\" RW failed", bin_path);
// Open ELF readwrite
if ((e = elf_begin(fd, ELF_C_RDWR, NULL)) == NULL)
errx(EXIT_FAILURE, "elf_begin() failed: %s.", elf_errmsg(-1));
// 2. Create new section
if ((scn = elf_newscn(e)) == NULL)
errx(EXIT_FAILURE, "elf_newscn() failed: %s.", elf_errmsg(-1));
if ((data = elf_newdata(scn)) == NULL)
errx(EXIT_FAILURE, "elf_newdata() failed: %s.",
elf_errmsg(-1));
data->d_align = 4;
data->d_buf = section_data_raw;
data->d_off = 0LL;
data->d_size = nread;
data->d_type = ELF_T_DYN;
data->d_version = EV_CURRENT;
scn_idx = elf_ndxscn(scn);
printf("New Section index: %zu\n", scn_idx);
scn = elf_getscn(e, scn_idx);
if ((shdr = elf64_getshdr(scn)) == NULL ){
err(EXIT_FAILURE, "elf64_getshdr() failed: %s.",
elf_errmsg(-1));
}
shdr->sh_name = scn_idx;
shdr->sh_type = SHT_PROGBITS;
shdr->sh_flags = SHF_ALLOC | SHF_WRITE;
shdr->sh_entsize = 0;
if (elf_update(e , ELF_C_NULL ) < 0) {
err(EXIT_FAILURE, "elf_update() failed: %s.",
Re: Cont.: Adding a new section to an ELF file aborts with Assertion `shdr != NULL'
Hi, On Fri, Dec 24, 2021 at 02:42:05PM -0600, P.B. via Elfutils-devel wrote: > Sorry I for some reason could not reply to the original thread here to > follow up: > https://www.mail-archive.com/elfutils-devel@sourceware.org/msg04076.html > > But I am facing the same issue, adding the section to a very simple ELF > file fails with Assertion `shdr != NULL'. I am new to this so I am sure I > am doing something wrong, but not exactly certain what it is. I have also > tried to open ELF with ELF_C_WRITE as opposed to ELF_C_RDWR but then my > error is "elf_newdata() failed: executable header not created first" so I > am not sure what the proper sequence of events would be to add a section. > > Below is my code and a run with the message. Unfortunately the original report didn't come with full example sources and your sources aren't complete either. But I just played a bit with some simple code that adds a section and I think it is a bug in libelf. As the original report said (in a followup) actually reading any of the existing section headers works around the assert. I think we missed this bug because normally you would at least read the existing section headers before adding new sections. Could you try first reading some section header before adding a new one? e.g. just add something like: scn = elf_nextscn(e, NULL); shdr = elf64_getshdr(scn); Hope that helps to workaround the bug for now. Cheers, Mark
Re: Cont.: Adding a new section to an ELF file aborts with Assertion `shdr != NULL'
Thank you, Mark. It worked. Sequence I followed: ``` // Open ELF readwrite if ((e = elf_begin(fd, ELF_C_RDWR, NULL)) == NULL) errx(EXIT_FAILURE, "elf_begin() failed: %s.", elf_errmsg(-1)); // Read existing section scn = elf_nextscn(e, NULL); shdr = elf64_getshdr(scn); // Create new section (index after last) if ((scn = elf_newscn(e)) == NULL) errx(EXIT_FAILURE, "elf_newscn() failed: %s.", elf_errmsg(-1)); ``` On Fri, Dec 24, 2021 at 4:15 PM Mark Wielaard wrote: > Hi, > > On Fri, Dec 24, 2021 at 02:42:05PM -0600, P.B. via Elfutils-devel wrote: > > Sorry I for some reason could not reply to the original thread here to > > follow up: > > https://www.mail-archive.com/elfutils-devel@sourceware.org/msg04076.html > > > > But I am facing the same issue, adding the section to a very simple ELF > > file fails with Assertion `shdr != NULL'. I am new to this so I am sure > I > > am doing something wrong, but not exactly certain what it is. I have also > > tried to open ELF with ELF_C_WRITE as opposed to ELF_C_RDWR but then my > > error is "elf_newdata() failed: executable header not created first" so I > > am not sure what the proper sequence of events would be to add a section. > > > > Below is my code and a run with the message. > > Unfortunately the original report didn't come with full example > sources and your sources aren't complete either. But I just played a > bit with some simple code that adds a section and I think it is a bug > in libelf. As the original report said (in a followup) actually > reading any of the existing section headers works around the assert. I > think we missed this bug because normally you would at least read the > existing section headers before adding new sections. > > Could you try first reading some section header before adding a new one? > e.g. just add something like: > scn = elf_nextscn(e, NULL); > shdr = elf64_getshdr(scn); > > Hope that helps to workaround the bug for now. > > Cheers, > > Mark >
[Bug tools/28723] New: "eu-size -A" does not display .comment and .note.GNU-stack
https://sourceware.org/bugzilla/show_bug.cgi?id=28723 Bug ID: 28723 Summary: "eu-size -A" does not display .comment and .note.GNU-stack Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: unassigned at sourceware dot org Reporter: panxh_ran at 163 dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13878 --> https://sourceware.org/bugzilla/attachment.cgi?id=13878&action=edit the result of eu-size -A Hello! The result of "eu-size -A" does not display section .comment and .note.GNU-stack which "size -A" can display. Please confirm the attachment. Would that be correct？ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28724] New: eu-elfclassify --no-stdin option is not effect
https://sourceware.org/bugzilla/show_bug.cgi?id=28724
Bug ID: 28724
Summary: eu-elfclassify --no-stdin option is not effect
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tools
Assignee: unassigned at sourceware dot org
Reporter: panxh_ran at 163 dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Created attachment 13879
--> https://sourceware.org/bugzilla/attachment.cgi?id=13879&action=edit
the result of eu-elfclassify --no-stdin
eu-elfclassify --no-stdin option still reads files from standard input.
It seems that "no-stdin" used wrong enum member classify_flag_stdin instead of
classify_flag_no_stdin in src/elfclassify.c
949 { "no-stdin", classify_flag_stdin, NULL, 0,
950 N_("Do not read files from standard input (default)"), 2 },
Please confirm the result of eu-elfclassify --no-stdin with the attachment.
--
You are receiving this mail because:
You are on the CC list for the bug.
