Re: [PATCH 1/1] bpf: fix TOCTOU in IPv6 SRH encapsulation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: unbounded GFP_ATOMIC allocation in bpf_push_seg6_encap()
--

commit 40c18c9d1b350ea4f5c75479e1a7e19a9afce134
Author: Luxiao Xu <rakukuip@gmail.com>

bpf: fix TOCTOU in IPv6 SRH encapsulation

This commit addresses a TOCTOU bug in BPF SRH encapsulation by duplicating
the user-supplied SRH using kmemdup() before validation. This prevents
concurrent map updates from altering the header while in use.

> diff --git a/net/core/filter.c b/net/core/filter.c
> index 532405988fd98..cbae40d545817 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -6878,16 +6878,22 @@ static const struct bpf_func_proto bpf_xdp_check_mtu_proto = {
>  #if IS_ENABLED(CONFIG_IPV6_SEG6_BPF)
>  static int bpf_push_seg6_encap(struct sk_buff *skb, u32 type, void *hdr, u32 len)
>  {
> -	int err;
> -	struct ipv6_sr_hdr *srh = (struct ipv6_sr_hdr *)hdr;
> +	struct ipv6_sr_hdr *srh;
> +	int err = -EINVAL;
> +
> +	srh = kmemdup(hdr, len, GFP_ATOMIC);

[Severity: Medium]
Could this lead to high-order page allocation failures? The unvalidated
length parameter is passed directly to an atomic memory allocator before
being validated.

If a privileged BPF program calls bpf_lwt_push_encap() with a large length
sourced from an array map, the verifier allows this since it is only bounded
by the map value size limit. Passing this length to kmemdup() before the
bounds check in seg6_validate_srh() restricts it can trigger atomic
allocation failures, leading to dmesg spam or a kernel panic if
panic_on_warn is set.

> +	if (!srh)
> +		return -ENOMEM;
>  
>  	if (!seg6_validate_srh(srh, len, false))
> -		return -EINVAL;
> +		goto out;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917163408.252431-1-weir@nebusec.ai?part=1