From: sashiko-bot@kernel.org
To: "Lorenzo Bianconi" <lorenzo.bianconi@oss.qualcomm.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net-next v10 2/4] net: xdp: add xdp_buff_shrink_tail() helper
Date: Fri, 13 Nov 2026 16:36:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-213209@kernel.org> (raw)
In-Reply-To: <20261112-stmmac-rx-mb-v10-2-d3d04b65c6bc@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] net: xdp: bounds check split in bpf_xdp_adjust_tail() allows
pointer wrap
--
commit fe8a696967ad3281fe5305e0444a8948ebb0b12e
Author: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
net: xdp: add xdp_buff_shrink_tail() helper
This commit moves the XDP tail-shrinking helpers from net/core/filter.c to
net/core/xdp.c and exports xdp_buff_shrink_tail() for driver use.
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 9b8d5191c4ba2..5ea45dfce7a22 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -4438,96 +4438,21 @@ static int bpf_xdp_frags_increase_tail(struct xdp_buff *xdp, int offset)
[ ... ]
> BPF_CALL_2(bpf_xdp_adjust_tail, struct xdp_buff *, xdp, int, offset)
> {
> void *data_hard_end = xdp_data_hard_end(xdp); /* use xdp->frame_sz */
> void *data_end = xdp->data_end + offset;
>
> - if (unlikely(xdp_buff_has_frags(xdp))) { /* non-linear xdp buff */
> - if (offset < 0)
> - return bpf_xdp_frags_shrink_tail(xdp, -offset);
> + if (offset < 0)
> + return xdp_buff_shrink_tail(xdp, -offset);
>
> + if (unlikely(xdp_buff_has_frags(xdp))) /* non-linear xdp buff */
> return bpf_xdp_frags_increase_tail(xdp, offset);
> - }
>
> /* Notice that xdp_data_hard_end have reserved some tailroom */
> if (unlikely(data_end > data_hard_end))
> return -EINVAL;
>
> - if (unlikely(data_end < xdp->data + ETH_HLEN))
> - return -EINVAL;
> -
> /* Clear memory area on grow, can contain uninit kernel memory */
> if (offset > 0)
> memset(xdp->data_end, 0, offset);
[ ... ]
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 470bf90d93ef2..7c98dbc2a770c 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -672,6 +672,97 @@ struct sk_buff *__xdp_build_skb_from_buff(const struct xdp_buff *xdp)
[ ... ]
> +int xdp_buff_shrink_tail(struct xdp_buff *xdp, int offset)
> +{
> + void *data_end = xdp->data_end - offset;
> +
> + if (unlikely(offset < 0))
> + return -EINVAL;
> +
> + if (unlikely(xdp_buff_has_frags(xdp))) /* non-linear xdp buff */
> + return xdp_frags_shrink_tail(xdp, offset);
> +
> + if (unlikely(data_end < xdp->data + ETH_HLEN))
> + return -EINVAL;
> +
> + xdp->data_end = data_end;
> +
> + return 0;
> +}
[Severity: High]
Can splitting the upper and lower bounds checks between bpf_xdp_adjust_tail()
and xdp_buff_shrink_tail() allow pointer wraparound on linear buffers?
Previously, bpf_xdp_adjust_tail() checked both data_end > data_hard_end and
data_end < xdp->data + ETH_HLEN on xdp->data_end + offset, which prevented
pointer arithmetic overflow or underflow from passing validation.
With the checks split:
1. In bpf_xdp_adjust_tail(), offset >= 0 now only checks
data_end > data_hard_end. On 32-bit architectures, a large positive offset
(e.g. 0x40000000) wraps xdp->data_end + offset past 0 to an address below
data_hard_end, bypassing the check and passing offset to
memset(xdp->data_end, 0, offset) for an out-of-bounds kernel memory write.
It also allows frames initially shorter than ETH_HLEN (such as L3 packets
on tun devices in generic XDP) to remain shorter than ETH_HLEN when
offset >= 0.
2. In xdp_buff_shrink_tail(), linear buffers only check
data_end < xdp->data + ETH_HLEN on xdp->data_end - offset. When
(uintptr_t)xdp->data_end < 0x80000000 (for example on s390x where
PAGE_OFFSET is 0, or 32-bit kernels with VMSPLIT_1G / VMSPLIT_2G_OPT), a
positive offset larger than xdp->data_end underflows data_end to a high
address above xdp->data + ETH_HLEN, setting xdp->data_end past
data_hard_end and exposing out-of-bounds memory to BPF packet accesses.
Checking offset against the integer buffer bounds (such as
offset > (int)(xdp->data_end - xdp->data) - ETH_HLEN in
xdp_buff_shrink_tail(), and keeping the ETH_HLEN and tailroom checks in
bpf_xdp_adjust_tail() overflow-safe) would avoid both wraparounds.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261112-stmmac-rx-mb-v10-0-d3d04b65c6bc@oss.qualcomm.com?part=2
next prev parent reply other threads:[~2026-11-13 16:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 16:34 [PATCH net-next v10 0/4] net: stmmac: introduce XDP rx multi-buff support Lorenzo Bianconi
2026-11-12 16:34 ` [PATCH net-next v10 1/4] net: xdp: add __xdp_build_skb_from_buff() helper Lorenzo Bianconi
2026-11-12 16:34 ` [PATCH net-next v10 2/4] net: xdp: add xdp_buff_shrink_tail() helper Lorenzo Bianconi
2026-11-13 16:36 ` sashiko-bot [this message]
2026-11-12 16:34 ` [PATCH net-next v10 3/4] net: xdp: add __xdp_return_buff() helper Lorenzo Bianconi
2026-11-12 16:34 ` [PATCH net-next v10 4/4] net: stmmac: rework stmmac_rx to support XDP rx multi-buff Lorenzo Bianconi
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=sashiko-outbox-213209@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=lorenzo.bianconi@oss.qualcomm.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.