* [PATCH bpf] bpf: Do not close un-owned FD 0 on errors
@ 2021-07-28 23:09 Daniel Xu
2021-07-29 6:22 ` Yonghong Song
2021-07-29 23:16 ` Andrii Nakryiko
0 siblings, 2 replies; 3+ messages in thread
From: Daniel Xu @ 2021-07-28 23:09 UTC (permalink / raw
To: andrii; +Cc: Daniel Xu, bpf, kernel-team
Before this patch, btf_new() was liable to close an arbitrary FD 0 if
BTF parsing failed. This was because:
* btf->fd was initialized to 0 through the calloc()
* btf__free() (in the `done` label) closed any FDs >= 0
* btf->fd is left at 0 if parsing fails
This issue was discovered on a system using libbpf v0.3 (without
BTF_KIND_FLOAT support) but with a kernel that had BTF_KIND_FLOAT types
in BTF. Thus, parsing fails.
While this patch technically doesn't fix any issues b/c upstream libbpf
has BTF_KIND_FLOAT support, it'll help prevent issues in the future if
more BTF types are added. It also allow the fix to be backported to
older libbpf's.
Fixes: 3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness")
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
---
tools/lib/bpf/btf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
index b46760b93bb4..7ff3d5ce44f9 100644
--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@ -804,6 +804,7 @@ static struct btf *btf_new(const void *data, __u32 size, struct btf *base_btf)
btf->nr_types = 0;
btf->start_id = 1;
btf->start_str_off = 0;
+ btf->fd = -1;
if (base_btf) {
btf->base_btf = base_btf;
@@ -832,8 +833,6 @@ static struct btf *btf_new(const void *data, __u32 size, struct btf *base_btf)
if (err)
goto done;
- btf->fd = -1;
-
done:
if (err) {
btf__free(btf);
--
2.31.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH bpf] bpf: Do not close un-owned FD 0 on errors
2021-07-28 23:09 [PATCH bpf] bpf: Do not close un-owned FD 0 on errors Daniel Xu
@ 2021-07-29 6:22 ` Yonghong Song
2021-07-29 23:16 ` Andrii Nakryiko
1 sibling, 0 replies; 3+ messages in thread
From: Yonghong Song @ 2021-07-29 6:22 UTC (permalink / raw
To: Daniel Xu, andrii; +Cc: bpf, kernel-team
On 7/28/21 4:09 PM, Daniel Xu wrote:
> Before this patch, btf_new() was liable to close an arbitrary FD 0 if
> BTF parsing failed. This was because:
>
> * btf->fd was initialized to 0 through the calloc()
> * btf__free() (in the `done` label) closed any FDs >= 0
> * btf->fd is left at 0 if parsing fails
>
> This issue was discovered on a system using libbpf v0.3 (without
> BTF_KIND_FLOAT support) but with a kernel that had BTF_KIND_FLOAT types
> in BTF. Thus, parsing fails.
>
> While this patch technically doesn't fix any issues b/c upstream libbpf
> has BTF_KIND_FLOAT support, it'll help prevent issues in the future if
> more BTF types are added. It also allow the fix to be backported to
> older libbpf's.
>
> Fixes: 3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness")
> Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH bpf] bpf: Do not close un-owned FD 0 on errors
2021-07-28 23:09 [PATCH bpf] bpf: Do not close un-owned FD 0 on errors Daniel Xu
2021-07-29 6:22 ` Yonghong Song
@ 2021-07-29 23:16 ` Andrii Nakryiko
1 sibling, 0 replies; 3+ messages in thread
From: Andrii Nakryiko @ 2021-07-29 23:16 UTC (permalink / raw
To: Daniel Xu; +Cc: Andrii Nakryiko, bpf, Kernel Team
On Wed, Jul 28, 2021 at 4:09 PM Daniel Xu <dxu@dxuuu.xyz> wrote:
>
> Before this patch, btf_new() was liable to close an arbitrary FD 0 if
> BTF parsing failed. This was because:
>
> * btf->fd was initialized to 0 through the calloc()
> * btf__free() (in the `done` label) closed any FDs >= 0
> * btf->fd is left at 0 if parsing fails
>
> This issue was discovered on a system using libbpf v0.3 (without
> BTF_KIND_FLOAT support) but with a kernel that had BTF_KIND_FLOAT types
> in BTF. Thus, parsing fails.
>
> While this patch technically doesn't fix any issues b/c upstream libbpf
> has BTF_KIND_FLOAT support, it'll help prevent issues in the future if
> more BTF types are added. It also allow the fix to be backported to
> older libbpf's.
>
> Fixes: 3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness")
> Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> ---
Thanks! Applied to bpf. We should bite a bullet and make sure that
libbpf itself never uses/allows FD 0 internally (by, say, dup()'ing FD
0, if we happen to get it) and get rid of the -1 special initializers.
> tools/lib/bpf/btf.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index b46760b93bb4..7ff3d5ce44f9 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -804,6 +804,7 @@ static struct btf *btf_new(const void *data, __u32 size, struct btf *base_btf)
> btf->nr_types = 0;
> btf->start_id = 1;
> btf->start_str_off = 0;
> + btf->fd = -1;
>
> if (base_btf) {
> btf->base_btf = base_btf;
> @@ -832,8 +833,6 @@ static struct btf *btf_new(const void *data, __u32 size, struct btf *base_btf)
> if (err)
> goto done;
>
> - btf->fd = -1;
> -
> done:
> if (err) {
> btf__free(btf);
> --
> 2.31.1
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-07-29 23:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-07-28 23:09 [PATCH bpf] bpf: Do not close un-owned FD 0 on errors Daniel Xu
2021-07-29 6:22 ` Yonghong Song
2021-07-29 23:16 ` Andrii Nakryiko
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.