BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Nick Hudson" <nhudson@akamai.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v7 6/6] selftests/bpf: tc_tunnel - validate decap GSO and encapsulation state
Date: Wed, 12 Aug 2026 10:20:04 +0000	[thread overview]
Message-ID: <20260812102004.BF6001F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812083115.73100-7-nhudson@akamai.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Invalid pointer arithmetic `kskb->head + kskb->end` breaks 32-bit compilation and cross-architecture CO-RE portability.
--

--- Patch [6]: [PATCH bpf-next v7 6/6] selftests/bpf: tc_tunnel - validate decap GSO and encapsulation state ---
commit 51cad3ba4cd10bce6b9c9134b5e4188fc76f034c
Author: Nick Hudson <nhudson@akamai.com>
selftests/bpf: tc_tunnel - validate decap GSO and encapsulation state

This commit tightens tc_tunnel tests by verifying post-decap tunnel
state for both GSO and non-GSO packets. It enforces DECAP flags and
ensures proper clearing of gso_type bits and encapsulation state.

> diff --git a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
> --- a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
> +++ b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c

[ ... ]

> @@ -655,6 +688,40 @@ static int decap_internal(struct __sk_buff *skb, int off, int len, char proto)
>  	if (bpf_skb_adjust_room(skb, -olen, BPF_ADJ_ROOM_MAC, flags))
>  		return TC_ACT_SHOT;
>  
> +	kskb = bpf_cast_to_kern_ctx(skb);
> +	shinfo = bpf_core_cast(kskb->head + kskb->end, struct skb_shared_info);
                                       ^^^^^^^^^^^^^^^^^^^^^

[Severity: Medium]
Does this pointer arithmetic break compilation on 32-bit architectures?

Since kskb->end is a pointer on 32-bit systems (rather than an integer offset
like it is on 64-bit), adding kskb->head and kskb->end together attempts to add
two pointers, which is invalid in C.

Additionally, CO-RE does not translate this pointer-integer addition to a single
pointer dereference when cross-compiled on 64-bit and run on 32-bit kernels,
which can lead to a garbage pointer dereference.

Is there a safer way to calculate the skb_shared_info offset in decap_internal
that is portable across both 32-bit and 64-bit architectures?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812083115.73100-1-nhudson@akamai.com?part=6

  reply	other threads:[~2026-08-12 10:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12  8:31 [PATCH bpf-next v7 0/6] bpf: decap flags and GSO state updates Nick Hudson
2026-08-12  8:31 ` [PATCH bpf-next v7 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags Nick Hudson
2026-08-12  8:31 ` [PATCH bpf-next v7 2/6] bpf: refactor masks for ADJ_ROOM flags and encap validation Nick Hudson
2026-08-12 10:33   ` bot+bpf-ci
2026-08-12  8:31 ` [PATCH bpf-next v7 3/6] bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation Nick Hudson
2026-08-12  8:31 ` [PATCH bpf-next v7 4/6] bpf: allow new DECAP flags and add guard rails Nick Hudson
2026-08-12 10:22   ` sashiko-bot
2026-08-12 12:13     ` Hudson, Nick
2026-08-12 10:33   ` bot+bpf-ci
2026-08-12  8:31 ` [PATCH bpf-next v7 5/6] bpf: clear decap state on skb_adjust_room shrink path Nick Hudson
2026-08-12 10:26   ` sashiko-bot
2026-08-12 12:30     ` Hudson, Nick
2026-08-12 10:33   ` bot+bpf-ci
2026-08-12  8:31 ` [PATCH bpf-next v7 6/6] selftests/bpf: tc_tunnel - validate decap GSO and encapsulation state Nick Hudson
2026-08-12 10:20   ` sashiko-bot [this message]
2026-08-12 12:23     ` Hudson, Nick
2026-08-12 10:48   ` bot+bpf-ci

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=20260812102004.BF6001F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=nhudson@akamai.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