Re: [PATCH bpf 1/2] bpf: Fix OOB in bpf_obj_memcpy for cgroup storage

[Martin KaFai Lau <martin.lau@linux.dev>]

On 3/29/26 11:32 PM, xulang wrote:
>>From looking at git history on pcpu_init_value, the issue should be
>> introduced in commit d3bec0138bfb.

> I've tried for several days, to adjust 'offset' to match the 'data_end', but couldn't
> reproduce this OOB since there seems to be always a 'tail room' after the 'data_end'.
> I've checked how the buffer of a 'skb' is alloced, take driver 'e1000' for example,
> it has many complicated round-up operations, in my test, when I send a UDP package
> with payload size less than 210, the alloced buffer size of a skb seems to be always
> 448, I've also checked the validity of its KASAN shadow memory, it also says 448. when
> I go on increasing the payload size(over 210), for example, 211, the buffer size grows
> sharply, I haven't found out when the 'data_end' reaches the 'tail end' yet, different
> NIC driver may behave differently on the 'tail room'?

It is hard to audit all possible sources.

> In my opinion, 'pcpu_init_value' shouldn't read 8 bytes if it has
> no guarantee that the 'src' is rounded up to 8-bytes.

so make sense not to read more than what the verifier has verified.

Before commit d3bec0138bfb, it didn't round up.
The current pcpu_copy_value() also uses copy_map_value() instead of 
copy_map_value_long().