All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.