AddressSanitizer: stack-overflow #483
Labels
Comments
|
It is probably caused by invalid BTF content. I found there is a CONST that type_id refers to itself. It should not happen for valid BTF content. Is it worth implementing cyclic detection here to validate the input data, perhaps only for debug builds? |
|
I am also wondering if this happens in the kernel as well. |
|
@ThinkerYzu1 this issue was found by the fuzz target by generating malformed data. Normally it shouldn't happen and it mostly can affect programs loading random stuff using |
|
Should be addressed by #617 |
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Aug 23, 2023
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>
danielocfb
pushed a commit
to danielocfb/kernel-patches-bpf
that referenced
this issue
Aug 23, 2023
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>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this issue
Aug 23, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Aug 23, 2023
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>
danielocfb
pushed a commit
to danielocfb/kernel-patches-bpf
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this issue
Aug 24, 2023
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>
danielocfb
pushed a commit
to danielocfb/kernel-patches-bpf
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this issue
Aug 24, 2023
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>
danielocfb
pushed a commit
to danielocfb/kernel-patches-bpf
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Aug 24, 2023
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>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this issue
Aug 24, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Aug 24, 2023
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>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Aug 25, 2023
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>
danielocfb
pushed a commit
to danielocfb/kernel-patches-bpf
that referenced
this issue
Aug 25, 2023
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>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this issue
Aug 25, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Aug 25, 2023
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>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this issue
Aug 27, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Aug 27, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Aug 28, 2023
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>
kernel-patches-daemon-bpf-rc bot
pushed a commit
to kernel-patches/bpf-rc
that referenced
this issue
Aug 28, 2023
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>
kernel-patches-daemon-bpf bot
pushed a commit
to kernel-patches/bpf
that referenced
this issue
Sep 8, 2023
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
anakryiko
added a commit
to anakryiko/libbpf
that referenced
this issue
Sep 15, 2023
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
anakryiko
added a commit
that referenced
this issue
Sep 15, 2023
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
|
OSS-Fuzz says the issue is gone: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42044. Closing. The other OSS-Fuzz issues should hopefully be closed automatically. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
./scripts/build-fuzzers.sh wget -O oss-fuzz-42044 https://oss-fuzz.com/download?testcase_id=4890914143731712 ./out/bpf-object-fuzzer oss-fuzz-42044The text was updated successfully, but these errors were encountered: