BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kuniyuki Iwashima" <kuniyu@google.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v1 bpf-next/net 4/5] bpf: Add kfunc to proxy TX HW Timestamp.
Date: Fri, 12 Jun 2026 00:33:05 +0000	[thread overview]
Message-ID: <20260612003305.53D791F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260612001803.23341-5-kuniyu@google.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] The TC_ACT_ERRQUEUE action is unhandled in sch_handle_egress(), causing packets to be silently transmitted instead of queued or dropped.

Pre-existing issues:
- [High] bpf_net_ctx_get_ri() will dereference a NULL pointer if bpf_skb_complete_tx_tstamp is called from a qdisc where bpf_net_ctx is not set.
--

commit 532ea1ea43e08b0ed268837eba11a8d463c7b97b
Author: Kuniyuki Iwashima <kuniyu@google.com>

bpf: Add kfunc to proxy TX HW Timestamp.

This patch introduces two new kfuncs, bpf_skb_scrub_tx_tstamp() and
bpf_skb_complete_tx_tstamp(), to proxy TX hardware timestamps for socket
applications using SCM_TIMESTAMPING. It also introduces the TCX_ERRQUEUE
action to enqueue the modified packet to the socket's error queue.

> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0c6c270d9f7d1..a86d10659cbbc 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
[ ... ]
> @@ -4504,6 +4539,10 @@ sch_handle_ingress(struct sk_buff *skb, struct packet_type **pt_prev, int *ret,
>  		*ret = NET_RX_DROP;
>  		bpf_net_ctx_clear(bpf_net_ctx);
>  		return NULL;
> +	case TC_ACT_ERRQUEUE:
> +		*ret = skb_do_completion(skb);
> +		bpf_net_ctx_clear(bpf_net_ctx);
> +		return NULL;

[Severity: High]
Does TC_ACT_ERRQUEUE also need to be handled in sch_handle_egress()?

If a BPF program returns TCX_ERRQUEUE on egress, the switch statement in
sch_handle_egress() will fall through. This clears the BPF network context
and returns the skb for transmission instead of queueing or dropping it,
which seems to bypass the intended error queue behavior.

[ ... ]
> diff --git a/net/core/filter.c b/net/core/filter.c
> index ab7adef9c0159..0bb8122f9f2eb 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
[ ... ]
> +__bpf_kfunc int bpf_skb_complete_tx_tstamp(struct __sk_buff *s,
> +					   struct bpf_tx_tstamp_cmpl *attrs,
> +					   int attrs__sz)
> +{
> +	struct sk_buff *skb = (struct sk_buff *)s;
> +	struct bpf_redirect_info *ri;
> +	struct sock *sk = skb->sk;
> +	s32 delta;
> +
> +	if (attrs__sz != sizeof(*attrs) || attrs->reserved)
> +		return -EINVAL;
> +
> +	if (!sk || !sk_fullsock(sk))
> +		return -EINVAL;

[Severity: High]
Should this function verify it is only called on ingress?

Without checking skb_at_tc_ingress(skb), bpf_skb_complete_tx_tstamp() could
be called on egress. If that happens and the program returns TCX_ERRQUEUE,
the completion state would be silently discarded and the packet transmitted
because sch_handle_egress() does not currently handle TC_ACT_ERRQUEUE.

> +
> +	if (attrs->payload_offset > skb->len)
> +		return -EINVAL;
> +
> +	delta = attrs->payload_offset - attrs->network_offset;
> +	switch (attrs->protocol) {
> +	case htons(ETH_P_IP):
> +		if (delta < (s32)sizeof(struct iphdr) || !sk_is_inet(sk))
> +			return -EINVAL;
> +		break;
> +	case htons(ETH_P_IPV6):
> +		if (delta < (s32)sizeof(struct ipv6hdr) || sk->sk_family != AF_INET6)
> +			return -EINVAL;
> +		break;
> +	default:
> +		return -EAFNOSUPPORT;
> +	}
> +
> +	ri = bpf_net_ctx_get_ri();

[Severity: High]
This is a pre-existing issue, but can bpf_net_ctx_get_ri() trigger a NULL
pointer dereference here under certain conditions?

When a BPF program runs via tcf_classify() from a traditional classful qdisc
enqueue callback (like HTB), sch_handle_egress() has already cleared the
bpf_net_ctx. Calling this kfunc in that scenario would cause
bpf_net_ctx_get_ri() to dereference a NULL pointer.

> +	ri->kern_flags |= BPF_RI_F_TX_TS_CMPL;
> +	ri->txtscmpl = *attrs;
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612001803.23341-1-kuniyu@google.com?part=4

  reply	other threads:[~2026-06-12  0:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12  0:17 [PATCH v1 bpf-next/net 0/5] bpf: Support RX/TX HW timestamp proxy Kuniyuki Iwashima
2026-06-12  0:17 ` [PATCH v1 bpf-next/net 1/5] ethtool: Introduce ETHTOOL_MSG_TSINFO_SET for virtual interfaces Kuniyuki Iwashima
2026-06-12  0:17 ` [PATCH v1 bpf-next/net 2/5] bpf: Rename bpf_kfunc_set_tcp_reqsk to bpf_kfunc_set_sched_cls Kuniyuki Iwashima
2026-06-12  0:17 ` [PATCH v1 bpf-next/net 3/5] bpf: Add bpf_skb_set_hwtstamp() Kuniyuki Iwashima
2026-06-12  0:33   ` sashiko-bot
2026-06-12  5:41     ` Kuniyuki Iwashima
2026-06-12  0:17 ` [PATCH v1 bpf-next/net 4/5] bpf: Add kfunc to proxy TX HW Timestamp Kuniyuki Iwashima
2026-06-12  0:33   ` sashiko-bot [this message]
2026-06-12  5:59     ` Kuniyuki Iwashima
2026-06-12  3:37   ` Alexei Starovoitov
2026-06-12  4:16     ` Kuniyuki Iwashima
2026-06-12  0:17 ` [PATCH v1 bpf-next/net 5/5] selftest: bpf: Add test for hwtstamp proxy Kuniyuki Iwashima
2026-06-12  0:31   ` sashiko-bot
2026-06-12  6:03     ` Kuniyuki Iwashima
2026-06-12 16:04       ` Alexei Starovoitov
2026-06-12 18:55         ` Kuniyuki Iwashima

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=20260612003305.53D791F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kuniyu@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox