-
Notifications
You must be signed in to change notification settings - Fork 401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libbpf: implement BTF validator #617
Comments
Hey @anakryiko, I'm getting back on track with this patch. So, what I've been trying to do is to add a function Now I need to figure out which BTF validations I should add to the libbpf side. I'm not very familiar with BTF, sorry (checking Also, can I send you patches off list before I send them to the mailing list? Or is it better to send it on the bpf mailing list for feedbacks? |
hey @retpolanne, I think that maybe implementing validation as BTF API would make sense, as it will allow other use cases to reuse this logic. So maybe add btf__validate() API to libbpf/src/btf.c and then use that from libbpf.c? Other than that, adding call to btf__validate() from bpf_object__init_btf() makes sense. Please send patches straight to mailing list. |
@anakryiko that sounds like a great idea! I’m also checking kernel/bpf/btf.c and saw some of the validations there such as iterating through types. That sounds like a plan. As I’m working I’ll send it to the mailing list then, thanks! |
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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. 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. 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 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 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 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 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 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 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 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
Validate BTF for basic sanity before using its contents. This will prevent most of reported fuzz errors and will increase overall robustness.
The text was updated successfully, but these errors were encountered: