All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH bpf] bpf: potential double-free of env->insn_aux_data
@ 2025-09-12 19:18 Eduard Zingerman
  2025-09-15 11:42 ` Daniel Borkmann
  0 siblings, 1 reply; 4+ messages in thread
From: Eduard Zingerman @ 2025-09-12 19:18 UTC (permalink / raw)
  To: bpf, ast, andrii
  Cc: daniel, martin.lau, kernel-team, yonghong.song, eddyz87,
	Chris Mason

Function bpf_patch_insn_data() has the following structure:

  static struct bpf_prog *bpf_patch_insn_data(... env ...)
  {
        struct bpf_prog *new_prog;
        struct bpf_insn_aux_data *new_data = NULL;

        if (len > 1) {
                new_data = vrealloc(...);  // <--------- (1)
                if (!new_data)
                        return NULL;

                env->insn_aux_data = new_data;  // <---- (2)
        }

        new_prog = bpf_patch_insn_single(env->prog, off, patch, len);
        if (IS_ERR(new_prog)) {
                ...
                vfree(new_data);   // <----------------- (3)
                return NULL;
        }
        ... happy path ...
  }

In case if bpf_patch_insn_single() returns an error the `new_data`
allocated at (1) will be freed at (3). However, at (2) this pointer
is stored in `env->insn_aux_data`. Which is freed unconditionally
by verifier.c:bpf_check() on both happy and error paths.
Thus, leading to double-free.

Fix this by removing vfree() call at (3), ownership over `new_data` is
already passed to `env->insn_aux_data` at this point.

Fixes: 77620d126739 ("bpf: use realloc in bpf_patch_insn_data")
Reported-by: Chris Mason <clm@meta.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
---
 kernel/bpf/verifier.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 9fb1f957a09374e4d148402572b872bec930f34c..92eb0f4e87a4ec3a7e303c6949cb415e3fd0b4ac 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -20781,7 +20781,6 @@ static struct bpf_prog *bpf_patch_insn_data(struct bpf_verifier_env *env, u32 of
 			verbose(env,
 				"insn %d cannot be patched due to 16-bit range\n",
 				env->insn_aux_data[off].orig_idx);
-		vfree(new_data);
 		return NULL;
 	}
 	adjust_insn_aux_data(env, new_data, new_prog, off, len);

---
base-commit: 22f20375f5b71f30c0d6896583b93b6e4bba7279
change-id: 20250912-patch-insn-data-double-free-f7be62b9c4a9

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH bpf] bpf: potential double-free of env->insn_aux_data
  2025-09-12 19:18 [PATCH bpf] bpf: potential double-free of env->insn_aux_data Eduard Zingerman
@ 2025-09-15 11:42 ` Daniel Borkmann
  2025-09-15 18:21   ` Eduard Zingerman
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Borkmann @ 2025-09-15 11:42 UTC (permalink / raw)
  To: Eduard Zingerman, bpf, ast, andrii
  Cc: martin.lau, kernel-team, yonghong.song, Chris Mason

On 9/12/25 9:18 PM, Eduard Zingerman wrote:
> Function bpf_patch_insn_data() has the following structure:
> 
>    static struct bpf_prog *bpf_patch_insn_data(... env ...)
>    {
>          struct bpf_prog *new_prog;
>          struct bpf_insn_aux_data *new_data = NULL;
> 
>          if (len > 1) {
>                  new_data = vrealloc(...);  // <--------- (1)
>                  if (!new_data)
>                          return NULL;
> 
>                  env->insn_aux_data = new_data;  // <---- (2)
>          }
> 
>          new_prog = bpf_patch_insn_single(env->prog, off, patch, len);
>          if (IS_ERR(new_prog)) {
>                  ...
>                  vfree(new_data);   // <----------------- (3)
>                  return NULL;
>          }
>          ... happy path ...
>    }
> 
> In case if bpf_patch_insn_single() returns an error the `new_data`
> allocated at (1) will be freed at (3). However, at (2) this pointer
> is stored in `env->insn_aux_data`. Which is freed unconditionally
> by verifier.c:bpf_check() on both happy and error paths.
> Thus, leading to double-free.
> 
> Fix this by removing vfree() call at (3), ownership over `new_data` is
> already passed to `env->insn_aux_data` at this point.
> 
> Fixes: 77620d126739 ("bpf: use realloc in bpf_patch_insn_data")
> Reported-by: Chris Mason <clm@meta.com>
> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
> ---
>   kernel/bpf/verifier.c | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 9fb1f957a09374e4d148402572b872bec930f34c..92eb0f4e87a4ec3a7e303c6949cb415e3fd0b4ac 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -20781,7 +20781,6 @@ static struct bpf_prog *bpf_patch_insn_data(struct bpf_verifier_env *env, u32 of
>   			verbose(env,
>   				"insn %d cannot be patched due to 16-bit range\n",
>   				env->insn_aux_data[off].orig_idx);
> -		vfree(new_data);

I presume you mean bpf-next tree, otherwise we'd be adding a memory leak into bpf tree?

>   		return NULL;
>   	}
>   	adjust_insn_aux_data(env, new_data, new_prog, off, len);
Thanks,
Daniel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH bpf] bpf: potential double-free of env->insn_aux_data
  2025-09-15 11:42 ` Daniel Borkmann
@ 2025-09-15 18:21   ` Eduard Zingerman
  2025-09-15 19:28     ` Alexei Starovoitov
  0 siblings, 1 reply; 4+ messages in thread
From: Eduard Zingerman @ 2025-09-15 18:21 UTC (permalink / raw)
  To: Daniel Borkmann, bpf, ast, andrii
  Cc: martin.lau, kernel-team, yonghong.song, Chris Mason

On Mon, 2025-09-15 at 13:42 +0200, Daniel Borkmann wrote:

[...]

> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 9fb1f957a09374e4d148402572b872bec930f34c..92eb0f4e87a4ec3a7e303c6949cb415e3fd0b4ac 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -20781,7 +20781,6 @@ static struct bpf_prog *bpf_patch_insn_data(struct bpf_verifier_env *env, u32 of
> >   			verbose(env,
> >   				"insn %d cannot be patched due to 16-bit range\n",
> >   				env->insn_aux_data[off].orig_idx);
> > -		vfree(new_data);
> 
> I presume you mean bpf-next tree, otherwise we'd be adding a memory leak into bpf tree?

Hi Daniel,

Yes, the tag should be bpf-next.
Will resend with the correct tag.
I apologize, this was sloppy on my side.

[...]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH bpf] bpf: potential double-free of env->insn_aux_data
  2025-09-15 18:21   ` Eduard Zingerman
@ 2025-09-15 19:28     ` Alexei Starovoitov
  0 siblings, 0 replies; 4+ messages in thread
From: Alexei Starovoitov @ 2025-09-15 19:28 UTC (permalink / raw)
  To: Eduard Zingerman
  Cc: Daniel Borkmann, bpf, Alexei Starovoitov, Andrii Nakryiko,
	Martin KaFai Lau, Kernel Team, Yonghong Song, Chris Mason

On Mon, Sep 15, 2025 at 11:21 AM Eduard Zingerman <eddyz87@gmail.com> wrote:
>
> On Mon, 2025-09-15 at 13:42 +0200, Daniel Borkmann wrote:
>
> [...]
>
> > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > index 9fb1f957a09374e4d148402572b872bec930f34c..92eb0f4e87a4ec3a7e303c6949cb415e3fd0b4ac 100644
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -20781,7 +20781,6 @@ static struct bpf_prog *bpf_patch_insn_data(struct bpf_verifier_env *env, u32 of
> > >                     verbose(env,
> > >                             "insn %d cannot be patched due to 16-bit range\n",
> > >                             env->insn_aux_data[off].orig_idx);
> > > -           vfree(new_data);
> >
> > I presume you mean bpf-next tree, otherwise we'd be adding a memory leak into bpf tree?
>
> Hi Daniel,
>
> Yes, the tag should be bpf-next.
> Will resend with the correct tag.

No need to resend.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-09-15 19:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-12 19:18 [PATCH bpf] bpf: potential double-free of env->insn_aux_data Eduard Zingerman
2025-09-15 11:42 ` Daniel Borkmann
2025-09-15 18:21   ` Eduard Zingerman
2025-09-15 19:28     ` Alexei Starovoitov

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.