From: sashiko-bot@kernel.org
To: "Anil Kaushik" <anilkaushikwireless@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2] selftests/bpf: add XDP test for per-flow LRU_HASH window updates
Date: Fri, 02 Oct 2026 09:14:28 +0000 [thread overview]
Message-ID: <20261002091429.041811F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261002042201.3483076-1-anilkaushikwireless@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: xdp_lru_window parses TCP header incorrectly ignoring IPv4 ihl
--
commit 76a8e18822036a1270d2ff9fde06bd760faa505b
Author: Anil Kaushik <anilkaushikwireless@gmail.com>
selftests/bpf: add XDP test for per-flow LRU_HASH window updates
This commit introduces a new XDP program and BPF selftest to verify bounds
checking of value-internal arrays and per-flow key isolation. It simulates an
LRU_HASH map updating a rolling window based on TCP packet lengths.
> diff --git a/tools/testing/selftests/bpf/progs/xdp_lru_window.c b/tools/testing/selftests/bpf/progs/xdp_lru_window.c
> new file mode 100644
> index 0000000000000..27aa1509e6c02
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/xdp_lru_window.c
[ ... ]
> +SEC("xdp")
> +int xdp_lru_window(struct xdp_md *ctx)
> +{
> + void *data_end = (void *)(long)ctx->data_end;
> + void *data = (void *)(long)ctx->data;
[ ... ]
> + iph = (void *)(eth + 1);
> + if ((void *)(iph + 1) > data_end)
> + return XDP_PASS;
> + if (iph->protocol != IPPROTO_TCP)
> + return XDP_PASS;
> +
> + th = (void *)(iph + 1);
> + if ((void *)(th + 1) > data_end)
> + return XDP_PASS;
[Severity: Medium]
Does this parsing logic incorrectly assume a fixed 20-byte IPv4 header?
If an IPv4 packet contains IP options (where iph->ihl > 5), taking (iph + 1)
statically advances by the size of the IP header struct instead of the actual
length specified by iph->ihl * 4.
This could cause the flow tracking logic to extract the source and destination
ports from attacker-controlled IP options rather than the actual TCP header,
potentially allowing flow pollution.
Should the calculation advance by the dynamic length using iph->ihl?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261002042201.3483076-1-anilkaushikwireless@gmail.com?part=1
prev parent reply other threads:[~2026-10-02 9:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 4:22 [PATCH bpf-next v2] selftests/bpf: add XDP test for per-flow LRU_HASH window updates Anil Kaushik
2026-10-02 5:14 ` bot+bpf-ci
2026-10-02 9:14 ` sashiko-bot [this message]
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=20261002091429.041811F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anilkaushikwireless@gmail.com \
--cc=bpf@vger.kernel.org \
--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.