All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mahe Tardy" <mahe.tardy@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v6 3/6] bpf: add bpf_icmp_send kfunc
Date: Mon, 18 May 2026 16:25:56 +0000	[thread overview]
Message-ID: <20260518162556.BE85AC2BCB8@smtp.kernel.org> (raw)
In-Reply-To: <20260518122842.218522-4-mahe.tardy@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The BPF kfunc `bpf_icmp_send()` originates ICMPv6 DEST_UNREACH messages for IPv6 fragments other than the first fragment, violating RFC 4443.
--

commit 7a9ef91672faeb43ff51c256f81255a263f374aa
Author: Mahe Tardy <mahe.tardy@gmail.com>

bpf: add bpf_icmp_send kfunc

Adds a bpf_icmp_send() kfunc for cgroup_skb and tc BPF programs to reply
with ICMP/ICMPv6 destination unreachable messages. It clones the packet
to safely generate the ICMP response without altering the original skb,
and includes protection against recursion.

> diff --git a/net/core/filter.c b/net/core/filter.c
> --- a/net/core/filter.c
> +++ b/net/core/filter.c

[ ... ]

> @@ -12464,6 +12466,110 @@ __bpf_kfunc int bpf_xdp_pull_data(struct xdp_md *x, u32 len)
>  	return 0;
>  }
>  
> +static DEFINE_PER_CPU(bool, bpf_icmp_send_in_progress);
> +
> +/**
> + * bpf_icmp_send - Send an ICMP control message

[ ... ]

> +__bpf_kfunc int bpf_icmp_send(struct __sk_buff *skb_ctx, int type, int code)
> +{

[ ... ]

> +#if IS_ENABLED(CONFIG_IPV6)
> +	case htons(ETH_P_IPV6):
> +		if (type != ICMPV6_DEST_UNREACH)
> +			return -EOPNOTSUPP;
> +		if (code < 0 || code > ICMPV6_REJECT_ROUTE)
> +			return -EINVAL;
> +
> +		nskb = skb_clone(skb, GFP_ATOMIC);
> +		if (!nskb)
> +			return -ENOMEM;
> +
> +		if (!pskb_network_may_pull(nskb, sizeof(struct ipv6hdr))) {
> +			kfree_skb(nskb);
> +			return -EBADMSG;
> +		}
> +
> +		if (!skb_dst(nskb) && ip6_route_reply_fill_dst(nskb) < 0) {
> +			kfree_skb(nskb);
> +			return -EHOSTUNREACH;
> +		}
> +
> +		memset(IP6CB(nskb), 0, sizeof(struct inet6_skb_parm));
> +
> +		*in_progress = true;
> +		icmpv6_send(nskb, type, code, 0);

The commit message notes that "icmp_send will only reply to fragment 0".
While IPv4's __icmp_send() explicitly drops non-initial fragments, does
icmpv6_send() provide the same guarantee?

Looking at icmpv6_send(), the internal is_ineligible() check does not seem
to prevent replying to non-initial UDP/TCP fragments. Other kernel subsystems
that originate ICMPv6 errors, such as Netfilter's nf_send_unreach6(), appear
to manually parse extension headers via ipv6_skip_exthdr() and explicitly
drop non-initial fragments.

Will calling icmpv6_send() directly here originate ICMPv6 errors for every
fragment of a dropped fragmented IPv6 packet, violating RFC 4443 Section
2.4 (e.5)?

> +		*in_progress = false;
> +		kfree_skb(nskb);
> +		break;
> +#endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518122842.218522-1-mahe.tardy@gmail.com?part=3

  parent reply	other threads:[~2026-05-18 16:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18 12:28 [PATCH bpf-next v6 0/4] bpf: add icmp_send kfunc Mahe Tardy
2026-05-18 12:28 ` [PATCH bpf-next v6 1/6] net: move netfilter nf_reject_fill_skb_dst to core ipv4 Mahe Tardy
2026-05-18 13:07   ` bot+bpf-ci
2026-05-18 14:21     ` Mahe Tardy
2026-05-18 12:28 ` [PATCH bpf-next v6 2/6] net: move netfilter nf_reject6_fill_skb_dst to core ipv6 Mahe Tardy
2026-05-18 13:07   ` bot+bpf-ci
2026-05-18 14:22     ` Mahe Tardy
2026-05-18 12:28 ` [PATCH bpf-next v6 3/6] bpf: add bpf_icmp_send kfunc Mahe Tardy
2026-05-18 13:34   ` bot+bpf-ci
2026-05-18 14:26     ` Mahe Tardy
2026-05-18 16:17   ` Stanislav Fomichev
2026-05-18 17:18     ` Mahe Tardy
2026-05-19 21:20       ` Stanislav Fomichev
2026-05-18 16:25   ` sashiko-bot [this message]
2026-05-19  1:33   ` Jordan Rife
2026-05-20 18:48     ` Mahe Tardy
2026-05-18 12:28 ` [PATCH bpf-next v6 4/6] selftests/bpf: add bpf_icmp_send kfunc tests Mahe Tardy
2026-05-19  1:34   ` Jordan Rife
2026-05-20 19:15     ` Mahe Tardy
2026-05-18 12:28 ` [PATCH bpf-next v6 5/6] selftests/bpf: add bpf_icmp_send kfunc IPv6 tests Mahe Tardy
2026-05-18 13:21   ` bot+bpf-ci
2026-05-18 14:27     ` Mahe Tardy
2026-05-18 16:45   ` sashiko-bot
2026-05-18 18:13     ` Mahe Tardy
2026-05-18 12:28 ` [PATCH bpf-next v6 6/6] selftests/bpf: add bpf_icmp_send recursion test Mahe Tardy
2026-05-18 13:07   ` bot+bpf-ci
2026-05-18 14:39     ` Mahe Tardy
2026-05-18 17:07   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260518162556.BE85AC2BCB8@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=mahe.tardy@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.