All of lore.kernel.org
 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 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.