* perf-top: heap-buffer-overflow in elf_sec__is_text reported from ASan
@ 2021-06-18 9:17 Riccardo Mancini
2021-06-21 6:54 ` Jiri Slaby
0 siblings, 1 reply; 3+ messages in thread
From: Riccardo Mancini @ 2021-06-18 9:17 UTC (permalink / raw)
To: jirislaby, namhyung; +Cc: linux-perf-users, Ian Rogers, acme
Hi,
ASan reports a heap-buffer-overflow in elf_sec__is_text when using perf-top.
The bug is introduced by commit 6833e0b: "perf symbols: Resolve symbols against
debug file first" from Jiri Slaby.
This is the ASan output (with the source at perf/urgent).
$ make CC=clang CXX=clang++ EXTRA_CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" WERROR=0 NO_LIBPYTHON=1 DEBUG=1 NO_LIBPERL=1
[...]
# ASAN_OPTIONS=abort_on_error=1:disable_coredump=0:unmap_shadow_on_exit=1 ./perf top
=================================================================
==363148==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61300009add6 at pc 0x00000049875c bp 0x7f4f56446440 sp 0x7f4f56445bf0
READ of size 1 at 0x61300009add6 thread T6
#0 0x49875b in StrstrCheck(void*, char*, char const*, char const*) (/home/user/linux/tools/perf/perf+0x49875b)
#1 0x4d13a2 in strstr (/home/user/linux/tools/perf/perf+0x4d13a2)
#2 0xacae36 in elf_sec__is_text /home/user/linux/tools/perf/util/symbol-elf.c:176:9
#3 0xac3ec9 in elf_sec__filter /home/user/linux/tools/perf/util/symbol-elf.c:187:9
#4 0xac2c3d in dso__load_sym /home/user/linux/tools/perf/util/symbol-elf.c:1254:20
#5 0x883981 in dso__load /home/user/linux/tools/perf/util/symbol.c:1897:9
#6 0x8e6248 in map__load /home/user/linux/tools/perf/util/map.c:332:7
#7 0x8e66e5 in map__find_symbol /home/user/linux/tools/perf/util/map.c:366:6
#8 0x7f8278 in machine__resolve /home/user/linux/tools/perf/util/event.c:707:13
#9 0x5f3d1a in perf_event__process_sample /home/user/linux/tools/perf/builtin-top.c:773:6
#10 0x5f30e4 in deliver_event /home/user/linux/tools/perf/builtin-top.c:1197:3
#11 0x908a72 in do_flush /home/user/linux/tools/perf/util/ordered-events.c:244:9
#12 0x905fae in __ordered_events__flush /home/user/linux/tools/perf/util/ordered-events.c:323:8
#13 0x9058db in ordered_events__flush /home/user/linux/tools/perf/util/ordered-events.c:341:9
#14 0x5f19b1 in process_thread /home/user/linux/tools/perf/builtin-top.c:1109:7
#15 0x7f4f6a21a298 in start_thread /usr/src/debug/glibc-2.33-16.fc34.x86_64/nptl/pthread_create.c:481:8
#16 0x7f4f697d0352 in clone ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
0x61300009add6 is located 10 bytes to the right of 332-byte region [0x61300009ac80,0x61300009adcc)
allocated by thread T6 here:
#0 0x4f3f7f in malloc (/home/user/linux/tools/perf/perf+0x4f3f7f)
#1 0x7f4f6a0a88d9 (/lib64/libelf.so.1+0xa8d9)
Thread T6 created by T0 here:
#0 0x464856 in pthread_create (/home/user/linux/tools/perf/perf+0x464856)
#1 0x5f06e0 in __cmd_top /home/user/linux/tools/perf/builtin-top.c:1309:6
#2 0x5ef19f in cmd_top /home/user/linux/tools/perf/builtin-top.c:1762:11
#3 0x7b28c0 in run_builtin /home/user/linux/tools/perf/perf.c:313:11
#4 0x7b119f in handle_internal_command /home/user/linux/tools/perf/perf.c:365:8
#5 0x7b2423 in run_argv /home/user/linux/tools/perf/perf.c:409:2
#6 0x7b0c19 in main /home/user/linux/tools/perf/perf.c:539:3
#7 0x7f4f696f7b74 in __libc_start_main /usr/src/debug/glibc-2.33-16.fc34.x86_64/csu/../csu/libc-start.c:332:16
SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/user/linux/tools/perf/perf+0x49875b) in StrstrCheck(void*, char*, char const*, char const*)
Shadow bytes around the buggy address:
0x0c268000b560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c268000b570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c268000b580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c268000b590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c268000b5a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c268000b5b0: 00 00 00 00 00 00 00 00 00 04[fa]fa fa fa fa fa
0x0c268000b5c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c268000b5d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c268000b5e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c268000b5f0: 07 fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c268000b600: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==363148==ABORTING
Here is some more information from the coredump:
pwndbg> p *shdr
$1 = {
sh_name = 342,
sh_type = 1,
sh_flags = 0,
sh_addr = 0,
sh_offset = 8472,
sh_size = 1140436,
sh_link = 0,
sh_info = 0,
sh_addralign = 1,
sh_entsize = 0
}
pwndbg> p *secstrs
$2 = {
d_buf = 0x6130001836c0,
d_type = ELF_T_BYTE,
d_version = 1,
d_size = 332,
d_off = 0,
d_align = 1
}
pwndbg> p syms_ss->name
$4 = 0x607000018f90 "/usr/lib/debug/usr/lib64/libglib-2.0.so.0.6800.2-2.68.2-1.fc34.x86_64.debug"
pwndbg> p runtime_ss->name
$5 = 0x6070000190e0 "/root/.debug/.build-id/37/475e3b392fb3971c8ad0d9ac0a4d7e1b93c521/elf"
Furthermore, the branch in line symbol-elf.c:1241 (the one added in the referred
patch) is not taken.
As you can see, sh_name is out-of-range (342 > 332).
I can also provide a coredump, if it can be useful.
I have no idea of how the ELF stuff works, but I thought this may be caused by
the fact that secstrs is built from runtime_ss, while shdr is built from syms_ss
(since it is the change of the commit). I tried to test this theory with the
following change:
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a73345730ba9..8d2b692f11a2 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1146,7 +1146,7 @@ int dso__load_sym(struct dso *dso, struct map *map, struct symsrc *syms_ss,
if (symstrs == NULL)
goto out_elf_end;
- sec_strndx = elf_getscn(runtime_ss->elf, runtime_ss->ehdr.e_shstrndx);
+ sec_strndx = elf_getscn(elf, ehdr.e_shstrndx);
if (sec_strndx == NULL)
goto out_elf_end;
@@ -1244,6 +1244,14 @@ int dso__load_sym(struct dso *dso, struct map *map, struct symsrc *syms_ss,
* values for syms (invalid) and runtime (valid).
*/
if (shdr.sh_type == SHT_NOBITS) {
+ sec_strndx = elf_getscn(runtime_ss->elf, runtime_ss->ehdr.e_shstrndx);
+ if (sec_strndx == NULL)
+ goto out_elf_end;
+
+ secstrs = elf_getdata(sec_strndx, NULL);
+ if (secstrs == NULL)
+ goto out_elf_end;
+
sec = elf_getscn(runtime_ss->elf, sym.st_shndx);
if (!sec)
goto out_elf_end;
However, it still overflows, but oddly the branch is not taken before the
overflow. Is there some kind of state that gets changed in the ELF structs?
I also tried to just change line 1146 as in the diff below:
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index a73345730ba9..27c7e1d39323 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1146,7 +1146,7 @@ int dso__load_sym(struct dso *dso, struct map *map, struct symsrc *syms_ss,
if (symstrs == NULL)
goto out_elf_end;
- sec_strndx = elf_getscn(runtime_ss->elf, runtime_ss->ehdr.e_shstrndx);
+ sec_strndx = elf_getscn(elf, ehdr.e_shstrndx);
if (sec_strndx == NULL)
goto out_elf_end;
In this case, ASan reports no overflows. So, it looks like it kinda solves the
problem, but I don't know if it's correct.
What do you think?
Thanks,
Riccardo
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: perf-top: heap-buffer-overflow in elf_sec__is_text reported from ASan
2021-06-18 9:17 perf-top: heap-buffer-overflow in elf_sec__is_text reported from ASan Riccardo Mancini
@ 2021-06-21 6:54 ` Jiri Slaby
2021-06-21 14:15 ` Riccardo Mancini
0 siblings, 1 reply; 3+ messages in thread
From: Jiri Slaby @ 2021-06-21 6:54 UTC (permalink / raw)
To: Riccardo Mancini, namhyung; +Cc: linux-perf-users, Ian Rogers, acme
Hi,
On 18. 06. 21, 11:17, Riccardo Mancini wrote:
> ASan reports a heap-buffer-overflow in elf_sec__is_text when using perf-top.
> The bug is introduced by commit 6833e0b: "perf symbols: Resolve symbols against
> debug file first" from Jiri Slaby.
...
> pwndbg> p syms_ss->name
> $4 = 0x607000018f90 "/usr/lib/debug/usr/lib64/libglib-2.0.so.0.6800.2-2.68.2-1.fc34.x86_64.debug"
> pwndbg> p runtime_ss->name
> $5 = 0x6070000190e0 "/root/.debug/.build-id/37/475e3b392fb3971c8ad0d9ac0a4d7e1b93c521/elf"
Out of curiosity, could you post output of 'readelf -S' on both of them?
> Furthermore, the branch in line symbol-elf.c:1241 (the one added in the referred
> patch) is not taken.
>
> As you can see, sh_name is out-of-range (342 > 332).
> I can also provide a coredump, if it can be useful.
>
> I have no idea of how the ELF stuff works, but I thought this may be caused by
> the fact that secstrs is built from runtime_ss, while shdr is built from syms_ss
> (since it is the change of the commit). I tried to test this theory with the
> following change:
>
> diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> index a73345730ba9..8d2b692f11a2 100644
> --- a/tools/perf/util/symbol-elf.c
> +++ b/tools/perf/util/symbol-elf.c
> @@ -1146,7 +1146,7 @@ int dso__load_sym(struct dso *dso, struct map *map, struct symsrc *syms_ss,
> if (symstrs == NULL)
> goto out_elf_end;
>
> - sec_strndx = elf_getscn(runtime_ss->elf, runtime_ss->ehdr.e_shstrndx);
> + sec_strndx = elf_getscn(elf, ehdr.e_shstrndx);
> if (sec_strndx == NULL)
> goto out_elf_end;
>
> @@ -1244,6 +1244,14 @@ int dso__load_sym(struct dso *dso, struct map *map, struct symsrc *syms_ss,
> * values for syms (invalid) and runtime (valid).
> */
> if (shdr.sh_type == SHT_NOBITS) {
> + sec_strndx = elf_getscn(runtime_ss->elf, runtime_ss->ehdr.e_shstrndx);
> + if (sec_strndx == NULL)
> + goto out_elf_end;
> +
> + secstrs = elf_getdata(sec_strndx, NULL);
> + if (secstrs == NULL)
> + goto out_elf_end;
> +
> sec = elf_getscn(runtime_ss->elf, sym.st_shndx);
> if (!sec)
> goto out_elf_end;
>
> However, it still overflows, but oddly the branch is not taken before the
> overflow. Is there some kind of state that gets changed in the ELF structs?
Something like that should work. But you should reset sec_strndx also in
the else branch, IMO. So what about this?
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1081,7 +1081,7 @@ int dso__load_sym(struct dso *dso, struct map
*map, struct symsrc *syms_ss,
struct maps *kmaps = kmap ? map__kmaps(map) : NULL;
struct map *curr_map = map;
struct dso *curr_dso = dso;
- Elf_Data *symstrs, *secstrs;
+ Elf_Data *symstrs, *secstrs, *secstrs_run, *secstrs_sym;
uint32_t nr_syms;
int err = -1;
uint32_t idx;
@@ -1150,8 +1150,16 @@ int dso__load_sym(struct dso *dso, struct map
*map, struct symsrc *syms_ss,
if (sec_strndx == NULL)
goto out_elf_end;
- secstrs = elf_getdata(sec_strndx, NULL);
- if (secstrs == NULL)
+ secstrs_run = elf_getdata(sec_strndx, NULL);
+ if (secstrs_run == NULL)
+ goto out_elf_end;
+
+ sec_strndx = elf_getscn(elf, ehdr.e_shstrndx);
+ if (sec_strndx == NULL)
+ goto out_elf_end;
+
+ secstrs_sym = elf_getdata(sec_strndx, NULL);
+ if (secstrs_sym == NULL)
goto out_elf_end;
nr_syms = shdr.sh_size / shdr.sh_entsize;
@@ -1237,6 +1245,8 @@ int dso__load_sym(struct dso *dso, struct map
*map, struct symsrc *syms_ss,
gelf_getshdr(sec, &shdr);
+ secstrs = secstrs_sym;
+
/*
* We have to fallback to runtime when syms' section
header has
* NOBITS set. NOBITS results in file offset
(sh_offset) not
@@ -1249,6 +1259,7 @@ int dso__load_sym(struct dso *dso, struct map
*map, struct symsrc *syms_ss,
goto out_elf_end;
gelf_getshdr(sec, &shdr);
+ secstrs = secstrs_run;
}
if (is_label && !elf_sec__filter(&shdr, secstrs))
thanks,
--
js
--
js
suse labs
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: perf-top: heap-buffer-overflow in elf_sec__is_text reported from ASan
2021-06-21 6:54 ` Jiri Slaby
@ 2021-06-21 14:15 ` Riccardo Mancini
0 siblings, 0 replies; 3+ messages in thread
From: Riccardo Mancini @ 2021-06-21 14:15 UTC (permalink / raw)
To: Jiri Slaby, namhyung; +Cc: linux-perf-users, Ian Rogers, acme
Hi,
thank you very much for your reply!
On Mon, 2021-06-21 at 08:54 +0200, Jiri Slaby wrote:
> Hi,
>
> On 18. 06. 21, 11:17, Riccardo Mancini wrote:
> > ASan reports a heap-buffer-overflow in elf_sec__is_text when using perf-top.
> > The bug is introduced by commit 6833e0b: "perf symbols: Resolve symbols
> > against
> > debug file first" from Jiri Slaby.
> ...
> > pwndbg> p syms_ss->name
> > $4 = 0x607000018f90 "/usr/lib/debug/usr/lib64/libglib-2.0.so.0.6800.2-2.68.2-
> > 1.fc34.x86_64.debug"
> > pwndbg> p runtime_ss->name
> > $5 = 0x6070000190e0 "/root/.debug/.build-
> > id/37/475e3b392fb3971c8ad0d9ac0a4d7e1b93c521/elf"
>
> Out of curiosity, could you post output of 'readelf -S' on both of them?
Sure, I'll post it to the bottom of this email since it's quite long.
>
> > Furthermore, the branch in line symbol-elf.c:1241 (the one added in the
> > referred
> > patch) is not taken.
> >
> > As you can see, sh_name is out-of-range (342 > 332).
> > I can also provide a coredump, if it can be useful.
> >
> > I have no idea of how the ELF stuff works, but I thought this may be caused by
> > the fact that secstrs is built from runtime_ss, while shdr is built from
> > syms_ss
> > (since it is the change of the commit). I tried to test this theory with the
> > following change:
> >
> > diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> > index a73345730ba9..8d2b692f11a2 100644
> > --- a/tools/perf/util/symbol-elf.c
> > +++ b/tools/perf/util/symbol-elf.c
> > @@ -1146,7 +1146,7 @@ int dso__load_sym(struct dso *dso, struct map *map,
> > struct symsrc *syms_ss,
> > if (symstrs == NULL)
> > goto out_elf_end;
> >
> > - sec_strndx = elf_getscn(runtime_ss->elf, runtime_ss->ehdr.e_shstrndx);
> > + sec_strndx = elf_getscn(elf, ehdr.e_shstrndx);
> > if (sec_strndx == NULL)
> > goto out_elf_end;
> >
> > @@ -1244,6 +1244,14 @@ int dso__load_sym(struct dso *dso, struct map *map,
> > struct symsrc *syms_ss,
> > * values for syms (invalid) and runtime (valid).
> > */
> > if (shdr.sh_type == SHT_NOBITS) {
> > + sec_strndx = elf_getscn(runtime_ss->elf, runtime_ss-
> > >ehdr.e_shstrndx);
> > + if (sec_strndx == NULL)
> > + goto out_elf_end;
> > +
> > + secstrs = elf_getdata(sec_strndx, NULL);
> > + if (secstrs == NULL)
> > + goto out_elf_end;
> > +
> > sec = elf_getscn(runtime_ss->elf, sym.st_shndx);
> > if (!sec)
> > goto out_elf_end;
> >
> > However, it still overflows, but oddly the branch is not taken before the
> > overflow. Is there some kind of state that gets changed in the ELF structs?
>
> Something like that should work. But you should reset sec_strndx also in
> the else branch, IMO.
Oops, that was embarassing. I completely forgot that it was inside a loop.
> So what about this?
>
> --- a/tools/perf/util/symbol-elf.c
> +++ b/tools/perf/util/symbol-elf.c
> @@ -1081,7 +1081,7 @@ int dso__load_sym(struct dso *dso, struct map
> *map, struct symsrc *syms_ss,
> struct maps *kmaps = kmap ? map__kmaps(map) : NULL;
> struct map *curr_map = map;
> struct dso *curr_dso = dso;
> - Elf_Data *symstrs, *secstrs;
> + Elf_Data *symstrs, *secstrs, *secstrs_run, *secstrs_sym;
> uint32_t nr_syms;
> int err = -1;
> uint32_t idx;
> @@ -1150,8 +1150,16 @@ int dso__load_sym(struct dso *dso, struct map
> *map, struct symsrc *syms_ss,
> if (sec_strndx == NULL)
> goto out_elf_end;
>
> - secstrs = elf_getdata(sec_strndx, NULL);
> - if (secstrs == NULL)
> + secstrs_run = elf_getdata(sec_strndx, NULL);
> + if (secstrs_run == NULL)
> + goto out_elf_end;
> +
> + sec_strndx = elf_getscn(elf, ehdr.e_shstrndx);
> + if (sec_strndx == NULL)
> + goto out_elf_end;
> +
> + secstrs_sym = elf_getdata(sec_strndx, NULL);
> + if (secstrs_sym == NULL)
> goto out_elf_end;
>
> nr_syms = shdr.sh_size / shdr.sh_entsize;
> @@ -1237,6 +1245,8 @@ int dso__load_sym(struct dso *dso, struct map
> *map, struct symsrc *syms_ss,
>
> gelf_getshdr(sec, &shdr);
>
> + secstrs = secstrs_sym;
> +
> /*
> * We have to fallback to runtime when syms' section
> header has
> * NOBITS set. NOBITS results in file offset
> (sh_offset) not
> @@ -1249,6 +1259,7 @@ int dso__load_sym(struct dso *dso, struct map
> *map, struct symsrc *syms_ss,
> goto out_elf_end;
>
> gelf_getshdr(sec, &shdr);
> + secstrs = secstrs_run;
> }
>
> if (is_label && !elf_sec__filter(&shdr, secstrs))
It works, thanks!
>
> thanks,
> --
> js
>
Here are the ELF sections of the two files causing the bug:
# readelf -S /usr/lib/debug/usr/lib64/libglib-2.0.so.0.6800.2-2.68.2-1.fc34.x86_64.debug
There are 43 section headers, starting at offset 0x386ed0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .note.gnu.pr[...] NOTE 00000000000002a8 000002a8
0000000000000020 0000000000000000 A 0 0 8
[ 2] .note.gnu.bu[...] NOTE 00000000000002c8 000002c8
0000000000000024 0000000000000000 A 0 0 4
[ 3] .gnu.hash NOBITS 00000000000002f0 000002f0
000000000000341c 0000000000000000 A 4 0 8
[ 4] .dynsym NOBITS 0000000000003710 000002f0
000000000000bdd8 0000000000000018 A 5 1 8
[ 5] .dynstr NOBITS 000000000000f4e8 000002f0
0000000000009a40 0000000000000000 A 0 0 1
[ 6] .gnu.version NOBITS 0000000000018f28 000002f0
0000000000000fd2 0000000000000002 A 4 0 2
[ 7] .gnu.version_r NOBITS 0000000000019f00 000002f0
0000000000000150 0000000000000000 A 5 2 8
[ 8] .rela.dyn NOBITS 000000000001a050 000002f0
0000000000000e88 0000000000000018 A 4 0 8
[ 9] .rela.plt NOBITS 000000000001aed8 000002f0
0000000000001548 0000000000000018 AI 4 23 8
[10] .init NOBITS 000000000001d000 000002f0
000000000000001b 0000000000000000 AX 0 0 4
[11] .plt NOBITS 000000000001d020 000002f0
0000000000000e40 0000000000000010 AX 0 0 16
[12] .plt.sec NOBITS 000000000001de60 000002f0
0000000000000e30 0000000000000010 AX 0 0 16
[13] .text NOBITS 000000000001ec90 000002f0
000000000008d842 0000000000000000 AX 0 0 16
[14] .fini NOBITS 00000000000ac4d4 000002f0
000000000000000d 0000000000000000 AX 0 0 4
[15] .rodata NOBITS 00000000000ad000 00000300
000000000006878c 0000000000000000 A 0 0 32
[16] .stapsdt.base NOBITS 000000000011578c 00000300
0000000000000001 0000000000000000 A 0 0 1
[17] .eh_frame_hdr NOBITS 0000000000115790 00000300
000000000000470c 0000000000000000 A 0 0 4
[18] .eh_frame NOBITS 0000000000119ea0 00000300
000000000001ba00 0000000000000000 A 0 0 8
[19] .init_array NOBITS 00000000001373a8 00000300
0000000000000010 0000000000000008 WA 0 0 8
[20] .fini_array NOBITS 00000000001373b8 00000300
0000000000000008 0000000000000008 WA 0 0 8
[21] .data.rel.ro NOBITS 00000000001373c0 00000300
0000000000000240 0000000000000000 WA 0 0 32
[22] .dynamic NOBITS 0000000000137600 00000300
0000000000000210 0000000000000010 WA 5 0 8
[23] .got NOBITS 0000000000137810 00000300
00000000000007e0 0000000000000008 WA 0 0 8
[24] .data NOBITS 0000000000138000 00000300
00000000000005f8 0000000000000000 WA 0 0 32
[25] .probes NOBITS 00000000001385f8 00000300
0000000000000060 0000000000000000 WA 0 0 2
[26] .bss NOBITS 0000000000138660 00000300
0000000000000d10 0000000000000000 WA 0 0 32
[27] .comment PROGBITS 0000000000000000 00000300
000000000000005c 0000000000000001 MS 0 0 1
[28] .note.stapsdt NOTE 0000000000000000 0000035c
0000000000001554 0000000000000000 0 0 4
[29] .gnu.build.a[...] NOTE 000000000013b370 000018b0
00000000000005c8 0000000000000000 0 0 4
[30] .debug_aranges PROGBITS 0000000000000000 00001e78
00000000000002a0 0000000000000000 0 0 1
[31] .debug_info PROGBITS 0000000000000000 00002118
00000000001166d4 0000000000000000 0 0 1
[32] .debug_abbrev PROGBITS 0000000000000000 001187ec
000000000000dad6 0000000000000000 0 0 1
[33] .debug_line PROGBITS 0000000000000000 001262c2
000000000006cff4 0000000000000000 0 0 1
[34] .debug_str PROGBITS 0000000000000000 001932b6
000000000000d853 0000000000000001 MS 0 0 1
[35] .debug_line_str PROGBITS 0000000000000000 001a0b09
0000000000001037 0000000000000001 MS 0 0 1
[36] .debug_loclists PROGBITS 0000000000000000 001a1b40
00000000000c5cfc 0000000000000000 0 0 1
[37] .debug_rnglists PROGBITS 0000000000000000 0026783c
0000000000016ff6 0000000000000000 0 0 1
[38] .gdb_index PROGBITS 0000000000000000 0027e832
0000000000028f3a 0000000000000000 0 0 1
[39] .gnu_debugaltlink PROGBITS 0000000000000000 002a776c
000000000000003a 0000000000000000 0 0 1
[40] .symtab SYMTAB 0000000000000000 002a77a8
00000000000a3b18 0000000000000018 41 25913 8
[41] .strtab STRTAB 0000000000000000 0034b2c0
000000000003ba35 0000000000000000 0 0 1
[42] .shstrtab STRTAB 0000000000000000 00386cf5
00000000000001d4 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
# sudo readelf -S /root/.debug/.build-id/37/475e3b392fb3971c8ad0d9ac0a4d7e1b93c521/elf
There are 32 section headers, starting at offset 0x13d088:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .note.gnu.pr[...] NOTE 00000000000002a8 000002a8
0000000000000020 0000000000000000 A 0 0 8
[ 2] .note.gnu.bu[...] NOTE 00000000000002c8 000002c8
0000000000000024 0000000000000000 A 0 0 4
[ 3] .gnu.hash GNU_HASH 00000000000002f0 000002f0
000000000000341c 0000000000000000 A 4 0 8
[ 4] .dynsym DYNSYM 0000000000003710 00003710
000000000000bdd8 0000000000000018 A 5 1 8
[ 5] .dynstr STRTAB 000000000000f4e8 0000f4e8
0000000000009a40 0000000000000000 A 0 0 1
[ 6] .gnu.version VERSYM 0000000000018f28 00018f28
0000000000000fd2 0000000000000002 A 4 0 2
[ 7] .gnu.version_r VERNEED 0000000000019f00 00019f00
0000000000000150 0000000000000000 A 5 2 8
[ 8] .rela.dyn RELA 000000000001a050 0001a050
0000000000000e88 0000000000000018 A 4 0 8
[ 9] .rela.plt RELA 000000000001aed8 0001aed8
0000000000001548 0000000000000018 AI 4 23 8
[10] .init PROGBITS 000000000001d000 0001d000
000000000000001b 0000000000000000 AX 0 0 4
[11] .plt PROGBITS 000000000001d020 0001d020
0000000000000e40 0000000000000010 AX 0 0 16
[12] .plt.sec PROGBITS 000000000001de60 0001de60
0000000000000e30 0000000000000010 AX 0 0 16
[13] .text PROGBITS 000000000001ec90 0001ec90
000000000008d842 0000000000000000 AX 0 0 16
[14] .fini PROGBITS 00000000000ac4d4 000ac4d4
000000000000000d 0000000000000000 AX 0 0 4
[15] .rodata PROGBITS 00000000000ad000 000ad000
000000000006878c 0000000000000000 A 0 0 32
[16] .stapsdt.base PROGBITS 000000000011578c 0011578c
0000000000000001 0000000000000000 A 0 0 1
[17] .eh_frame_hdr PROGBITS 0000000000115790 00115790
000000000000470c 0000000000000000 A 0 0 4
[18] .eh_frame PROGBITS 0000000000119ea0 00119ea0
000000000001ba00 0000000000000000 A 0 0 8
[19] .init_array INIT_ARRAY 00000000001373a8 001363a8
0000000000000010 0000000000000008 WA 0 0 8
[20] .fini_array FINI_ARRAY 00000000001373b8 001363b8
0000000000000008 0000000000000008 WA 0 0 8
[21] .data.rel.ro PROGBITS 00000000001373c0 001363c0
0000000000000240 0000000000000000 WA 0 0 32
[22] .dynamic DYNAMIC 0000000000137600 00136600
0000000000000210 0000000000000010 WA 5 0 8
[23] .got PROGBITS 0000000000137810 00136810
00000000000007e0 0000000000000008 WA 0 0 8
[24] .data PROGBITS 0000000000138000 00137000
00000000000005f8 0000000000000000 WA 0 0 32
[25] .probes PROGBITS 00000000001385f8 001375f8
0000000000000060 0000000000000000 WA 0 0 2
[26] .bss NOBITS 0000000000138660 00137658
0000000000000d10 0000000000000000 WA 0 0 32
[27] .note.stapsdt NOTE 0000000000000000 00137658
0000000000001554 0000000000000000 0 0 4
[28] .gnu.build.a[...] NOTE 000000000013b370 00138bac
00000000000005c8 0000000000000000 0 0 4
[29] .gnu_debuglink PROGBITS 0000000000000000 00139174
0000000000000038 0000000000000000 0 0 4
[30] .gnu_debugdata PROGBITS 0000000000000000 001391ac
0000000000003d90 0000000000000000 0 0 1
[31] .shstrtab STRTAB 0000000000000000 0013cf3c
000000000000014c 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
Thanks,
Riccardo
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-06-21 14:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-18 9:17 perf-top: heap-buffer-overflow in elf_sec__is_text reported from ASan Riccardo Mancini
2021-06-21 6:54 ` Jiri Slaby
2021-06-21 14:15 ` Riccardo Mancini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).