Re: [PATCH bpf v5 1/2] bpf: Fix OOB in pcpu_init_value

[Alexei Starovoitov]

On Thu, Apr 2, 2026 at 10:01 AM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
>
> On Thu, Apr 02, 2026 at 07:17:17AM -0700, Alexei Starovoitov wrote:
> > On Thu, Apr 2, 2026 at 12:43 AM xulang <xulang@xxxxxxxxxxxxx> wrote:
> > >
> > > From: Lang Xu <xulang@xxxxxxxxxxxxx>
> > >
> > > An out-of-bounds read occurs when copying element from a
> > > BPF_MAP_TYPE_CGROUP_STORAGE map to another pcpu map with the
> > > same value_size that is not rounded up to 8 bytes.
> > >
> > > The issue happens when:
> > > 1. A CGROUP_STORAGE map is created with value_size not aligned to
> > >    8 bytes (e.g., 4 bytes)
> > > 2. A pcpu map is created with the same value_size (e.g., 4 bytes)
> > > 3. Update element in 2 with data in 1
> > >
> > > pcpu_init_value assumes that all sources are rounded up to 8 bytes,
> > > and invokes copy_map_value_long to make a data copy, However, the
> > > assumption doesn't stand since there are some cases where the source
> > > may not be rounded up to 8 bytes, e.g., CGROUP_STORAGE,
> >
> > why? Just round it up there instead of penalizing perf everywhere.
> >
> > > skb->data.
> >
> > what that means?
> >
> > pcpu_init_value() can access skb->data ?
>
> After bound check, the skb->data can be used in
> bpf_map_update_elem(&percpu_lru_map, &key, skb_data, BPF_NOEXIST)
> which will call pcpu_init_value().

I see, but if we round up on cgroup storage size the problem is gone,
right?
Doesn't matter what the source of the copy is.