AddressSanitizer: SEGV on unknown address #482

evverx · 2022-04-13T01:57:43Z

./scripts/build-fuzzers.sh
wget -O oss-fuzz-41410 https://oss-fuzz.com/download?testcase_id=5338681456590848
./out/bpf-object-fuzzer oss-fuzz-41410

INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 971673186
INFO: Loaded 1 modules   (10860 inline 8-bit counters): 10860 [0x6f2200, 0x6f4c6c),
INFO: Loaded 1 PC tables (10860 PCs): 10860 [0x680640,0x6aad00),
./out/bpf-object-fuzzer: Running 1 inputs 1 time(s) each.
Running: oss-fuzz-41410
AddressSanitizer:DEADLYSIGNAL
=================================================================
==96632==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000004 (pc 0x0000005f7330 bp 0x7fff3ea0ed80 sp 0x7fff3ea0ed40 T0)
==96632==The signal is caused by a READ memory access.
==96632==Hint: address points to the zero page.
    #0 0x5f7330 in btf_kind /home/vagrant/libbpf/src/./btf.h:402:9
    #1 0x5f7330 in btf__align_of /home/vagrant/libbpf/src/btf.c:642:15
    #2 0x5f7565 in btf__align_of /home/vagrant/libbpf/src/btf.c:666:12
    #3 0x5985b4 in bpf_object__collect_externs /home/vagrant/libbpf/src/libbpf.c:3697:22
    #4 0x55ea61 in bpf_object_open /home/vagrant/libbpf/src/libbpf.c:7107:16
    #5 0x55efbe in bpf_object__open_mem /home/vagrant/libbpf/src/libbpf.c:7171:20
    #6 0x553ee9 in LLVMFuzzerTestOneInput /home/vagrant/libbpf/fuzz/bpf-object-fuzzer.c:16:8
    #7 0x450f99 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/libbpf/out/bpf-object-fuzzer+0x450f99)
    #8 0x431a3f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/libbpf/out/bpf-object-fuzzer+0x431a3f)
    #9 0x4396fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/libbpf/out/bpf-object-fuzzer+0x4396fe)
    #10 0x428ba6 in main (/home/vagrant/libbpf/out/bpf-object-fuzzer+0x428ba6)
    #11 0x7feac47e155f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
    #12 0x7feac47e160b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
    #13 0x428bf4 in _start (/home/vagrant/libbpf/out/bpf-object-fuzzer+0x428bf4)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/vagrant/libbpf/src/./btf.h:402:9 in btf_kind
==96632==ABORTING

anakryiko · 2022-11-15T05:58:48Z

Should be addressed by #617

Implement a simple and straightforward BTF sanity check when loading BTF information for BPF ELF file. Right now it's very basic and just validates that all the string offsets and type IDs are within valid range. But even with such simple checks it fixes a bunch of crashes found by OSS fuzzer ([0]-[5]) and will allow fuzzer to make further progress. Some other invariants will be checked in follow up patches (like ensuring there is no infinite type loops), but this seems like a good start already. [0] libbpf/libbpf#482 [1] libbpf/libbpf#483 [2] libbpf/libbpf#485 [3] libbpf/libbpf#613 [4] libbpf/libbpf#618 [5] libbpf/libbpf#619 Closes: libbpf/libbpf#617 Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

Implement a simple and straightforward BTF sanity check when parsing BTF data. Right now it's very basic and just validates that all the string offsets and type IDs are within valid range. But even with such simple checks it fixes a bunch of crashes found by OSS fuzzer ([0]-[5]) and will allow fuzzer to make further progress. Some other invariants will be checked in follow up patches (like ensuring there is no infinite type loops), but this seems like a good start already. v1->v2: - fix array index_type vs type copy/paste error (Eduard); - add type ID check in FUNC_PROTO validation (Eduard); - move sanity check to btf parsing time (Martin). [0] libbpf/libbpf#482 [1] libbpf/libbpf#483 [2] libbpf/libbpf#485 [3] libbpf/libbpf#613 [4] libbpf/libbpf#618 [5] libbpf/libbpf#619 Closes: libbpf/libbpf#617 Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

Implement a simple and straightforward BTF sanity check when parsing BTF data. Right now it's very basic and just validates that all the string offsets and type IDs are within valid range. For FUNC we also check that it points to FUNC_PROTO kinds. Even with such simple checks it fixes a bunch of crashes found by OSS fuzzer ([0]-[5]) and will allow fuzzer to make further progress. Some other invariants will be checked in follow up patches (like ensuring there is no infinite type loops), but this seems like a good start already. Adding FUNC -> FUNC_PROTO check revealed that one of selftests has a problem with FUNC pointing to VAR instead, so fix it up in the same commit. [0] libbpf/libbpf#482 [1] libbpf/libbpf#483 [2] libbpf/libbpf#485 [3] libbpf/libbpf#613 [4] libbpf/libbpf#618 [5] libbpf/libbpf#619 Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Song Liu <song@kernel.org> Closes: libbpf/libbpf#617 Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

Implement a simple and straightforward BTF sanity check when parsing BTF data. Right now it's very basic and just validates that all the string offsets and type IDs are within valid range. For FUNC we also check that it points to FUNC_PROTO kinds. Even with such simple checks it fixes a bunch of crashes found by OSS fuzzer ([0]-[5]) and will allow fuzzer to make further progress. Some other invariants will be checked in follow up patches (like ensuring there is no infinite type loops), but this seems like a good start already. Adding FUNC -> FUNC_PROTO check revealed that one of selftests has a problem with FUNC pointing to VAR instead, so fix it up in the same commit. [0] libbpf/libbpf#482 [1] libbpf/libbpf#483 [2] libbpf/libbpf#485 [3] libbpf/libbpf#613 [4] libbpf/libbpf#618 [5] libbpf/libbpf#619 Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Song Liu <song@kernel.org> Closes: libbpf/libbpf#617 Link: https://lore.kernel.org/bpf/20230825202152.1813394-1-andrii@kernel.org

Implement a simple and straightforward BTF sanity check when parsing BTF data. Right now it's very basic and just validates that all the string offsets and type IDs are within valid range. For FUNC we also check that it points to FUNC_PROTO kinds. Even with such simple checks it fixes a bunch of crashes found by OSS fuzzer ([0]-[5]) and will allow fuzzer to make further progress. Some other invariants will be checked in follow up patches (like ensuring there is no infinite type loops), but this seems like a good start already. Adding FUNC -> FUNC_PROTO check revealed that one of selftests has a problem with FUNC pointing to VAR instead, so fix it up in the same commit. [0] libbpf#482 [1] libbpf#483 [2] libbpf#485 [3] libbpf#613 [4] libbpf#618 [5] libbpf#619 Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Song Liu <song@kernel.org> Closes: libbpf#617 Link: https://lore.kernel.org/bpf/20230825202152.1813394-1-andrii@kernel.org

Implement a simple and straightforward BTF sanity check when parsing BTF data. Right now it's very basic and just validates that all the string offsets and type IDs are within valid range. For FUNC we also check that it points to FUNC_PROTO kinds. Even with such simple checks it fixes a bunch of crashes found by OSS fuzzer ([0]-[5]) and will allow fuzzer to make further progress. Some other invariants will be checked in follow up patches (like ensuring there is no infinite type loops), but this seems like a good start already. Adding FUNC -> FUNC_PROTO check revealed that one of selftests has a problem with FUNC pointing to VAR instead, so fix it up in the same commit. [0] #482 [1] #483 [2] #485 [3] #613 [4] #618 [5] #619 Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Song Liu <song@kernel.org> Closes: #617 Link: https://lore.kernel.org/bpf/20230825202152.1813394-1-andrii@kernel.org

evverx · 2023-09-16T09:20:54Z

OSS-Fuzz says it's gone: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41410. Closing.

anakryiko added the bug Something isn't working label Nov 15, 2022

anakryiko added fuzz-issue and removed bug Something isn't working labels Nov 15, 2022

anakryiko added the pending-fix label Aug 23, 2023

evverx closed this as completed Sep 16, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AddressSanitizer: SEGV on unknown address #482

AddressSanitizer: SEGV on unknown address #482

evverx commented Apr 13, 2022

anakryiko commented Nov 15, 2022

evverx commented Sep 16, 2023 •

edited

Loading

AddressSanitizer: SEGV on unknown address #482

AddressSanitizer: SEGV on unknown address #482

Comments

evverx commented Apr 13, 2022

anakryiko commented Nov 15, 2022

evverx commented Sep 16, 2023 • edited Loading

evverx commented Sep 16, 2023 •

edited

Loading