netdev - Re: [PATCH bpf v2 1/2] bpf: Disallow tail call to programs that use cgroup storage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMB2axOQDKrobzTVZhdafPks4fqYAN2HUrm_Asq3FG_GPSVw8A@mail.gmail.com>
Date: Tue, 2 Dec 2025 10:37:39 -0800
From: Amery Hung <ameryhung@...il.com>
To: Kumar Kartikeya Dwivedi <memxor@...il.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, alexei.starovoitov@...il.com, 
	andrii@...nel.org, daniel@...earbox.net, martin.lau@...nel.org, 
	eddyz87@...il.com, kernel-team@...a.com
Subject: Re: [PATCH bpf v2 1/2] bpf: Disallow tail call to programs that use
 cgroup storage

On Tue, Dec 2, 2025 at 9:27 AM Kumar Kartikeya Dwivedi <memxor@...il.com> wrote:
>
> On Tue, 2 Dec 2025 at 18:16, Amery Hung <ameryhung@...il.com> wrote:
> >
> > Mitigate a possible NULL pointer dereference in bpf_get_local_storage()
> > by disallowing tail call to programs that use cgroup storage. Cgroup
> > storage is allocated lazily when attaching a cgroup bpf program. With
> > tail call, it is possible for a callee BPF program to see a NULL
> > storage pointer if the caller prorgam does not use cgroup storage.
> >
> > Reported-by: Yinhao Hu <dddddd@...t.edu.cn>
> > Reported-by: Kaiyan Mei <M202472210@...t.edu.cn>
> > Reported-by: Dongliang Mu <dzm91@...t.edu.cn>
> > Closes: https://lore.kernel.org/bpf/c9ac63d7-73be-49c5-a4ac-eb07f7521adb@hust.edu.cn/
> > Signed-off-by: Amery Hung <ameryhung@...il.com>
> > ---
> >  kernel/bpf/arraymap.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> > index 1eeb31c5b317..9c3f86ef9d16 100644
> > --- a/kernel/bpf/arraymap.c
> > +++ b/kernel/bpf/arraymap.c
> > @@ -884,8 +884,9 @@ int bpf_fd_array_map_update_elem(struct bpf_map *map, struct file *map_file,
> >                                  void *key, void *value, u64 map_flags)
> >  {
> >         struct bpf_array *array = container_of(map, struct bpf_array, map);
> > +       u32 i, index = *(u32 *)key, ufd;
> >         void *new_ptr, *old_ptr;
> > -       u32 index = *(u32 *)key, ufd;
> > +       struct bpf_prog *prog;
> >
> >         if (map_flags != BPF_ANY)
> >                 return -EINVAL;
> > @@ -898,6 +899,14 @@ int bpf_fd_array_map_update_elem(struct bpf_map *map, struct file *map_file,
> >         if (IS_ERR(new_ptr))
> >                 return PTR_ERR(new_ptr);
> >
> > +       if (map->map_type == BPF_MAP_TYPE_PROG_ARRAY) {
> > +               prog = (struct bpf_prog *)new_ptr;
> > +
> > +               for_each_cgroup_storage_type(i)
> > +                       if (prog->aux->cgroup_storage[i])
> > +                               return -EINVAL;
> > +       }
>
> Would a similar check be needed for extension programs (BPF_PROG_TYPE_EXT)?

I think BPF_PROG_TYPE_EXT should be free from this NULL pointer
dereference bug. Since tail callee cannot be extended and extended
program cannot be tailcalled, an extension program calling
bpf_get_local_storage() must be directly called from a cgroup program
with a valid storage pointer.

However, I guess we also need to do something similar to [0] to
extension programs as well.

[0] https://lore.kernel.org/all/20250730234733.530041-4-daniel@iogearbox.net/

>
> > +
> >         if (map->ops->map_poke_run) {
> >                 mutex_lock(&array->aux->poke_mutex);
> >                 old_ptr = xchg(array->ptrs + index, new_ptr);
> > --
> > 2.47.3
> >
> >