Re: [PATCH bpf v1] bpf: Fix OOB in bpf_obj_memcpy for cgroup storage

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

On 3/16/26 6:51 AM, xulang wrote:
> From: Lang Xu <xulang@uniontech.com>
> 
>> Please create a selftest for this.
> 
> Going to do that. To stably reproduce this bug, I need the KASAN
> config enabled, how do I ensure it's enabled during a selftest cycle,
> by adding the line below to the 'config'? not quite sure.
> 
> --- a/tools/testing/selftests/bpf/config
> +++ b/tools/testing/selftests/bpf/config
> @@ -46,6 +46,7 @@ CONFIG_IPV6_GRE=y
>   CONFIG_IPV6_SEG6_BPF=y
>   CONFIG_IPV6_SIT=y
>   CONFIG_IPV6_TUNNEL=y
> +CONFIG_KASAN=y

I would leave out this config change from this fix for now. cc: Ihor to 
consider enabling it for bpf-next.

It is still useful to have a selftest for this case. I always have KASAN 
turned on when running selftests.


>> This is fixing the src side of the "copy_map_value_long(map, dst, src)".
>> The src could also be from a skb? What is the value_size that the
>> verifier is checking for bpf_map_update_elem?
> 
> The value_size checked by verifier is exactly the size with which
> the map is defined, i.e., not the size rounded up to 8-byte by kernel

If the verifier ensures only 4-bytes, I am not sure if the helper should 
read 8-bytes.

> 
> As for bpf_map_update_elem->..->copy_map_value_long, 'src' couldn't be from
> 'skb' which mismatches the expected ptr-type of 'bpf_map_update_elem',
> I've tried codes like these:
> 
> 1. bpf_map_update_elem(&lru_map, &key, skb, BPF_ANY);
> 2. bpf_map_update_elem(&lru_map, &key, skb->sk, BPF_ANY);  // null checked
> 3. bpf_map_update_elem(&lru_map, &key, skb->flow_keys, BPF_ANY);
> 
> All these ptrs mismatch the expected ptr-type, which can be detected by the verifier.
> The verifier complains with msg like 'R3 type=ctx expected=fp, pkt, pkt_meta, map_key,
> map_value, mem, ringbuf_mem, buf, trusted_ptr'

I meant the __sk_buff->data. Take a look at how skb->data can be used in 
the selftests. __sk_buff->data may not have readable bytes rounded up to 
8. Just one example that the src cannot always be fixed by allocating more.

 From looking at git history on pcpu_init_value, the issue should be 
introduced in commit d3bec0138bfb.