From: sashiko-bot@kernel.org
To: "Jason Xing" <kerneljasonxing@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net v4 1/5] xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata()
Date: Sat, 30 May 2026 00:44:16 +0000 [thread overview]
Message-ID: <20260530004416.702751F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260520004244.55663-2-kerneljasonxing@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Truncation of `hr + csum_start` to a 16-bit unsigned integer on systems with large pages (e.g., 64KB) leads to a negative checksum offset, causing out-of-bounds memory accesses and potential hardware DMA faults.
--
commit 7a5d0ad0065df9dde9ff7b2ebb8561268805c4e9
Author: Jason Xing <kerneljasonxing@gmail.com>
xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata()
This commit fixes a TOCTOU vulnerability in XSK TX metadata processing. It
reads csum_start and csum_offset from shared memory into local variables
once, then uses the local copies for both validation and assignment.
Closes: https://lore.kernel.org/all/20260503200927.73EA1C2BCB4@smtp.kernel.org/
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 5e5786cd9af55..f8c8a8c9dfba5 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -802,6 +802,7 @@ static int xsk_skb_metadata(struct sk_buff *skb, void *buffer,
[ ... ]
> if (meta->flags & XDP_TXMD_FLAGS_CHECKSUM) {
> - if (unlikely(meta->request.csum_start +
> - meta->request.csum_offset +
> + csum_start = READ_ONCE(meta->request.csum_start);
> + csum_offset = READ_ONCE(meta->request.csum_offset);
> +
> + if (unlikely(csum_start + csum_offset +
> sizeof(__sum16) > desc->len))
> return -EINVAL;
>
> - skb->csum_start = hr + meta->request.csum_start;
> - skb->csum_offset = meta->request.csum_offset;
> + skb->csum_start = hr + csum_start;
[Severity: High]
This is a pre-existing issue, but does this addition risk overflowing the
16-bit skb->csum_start on systems with large pages?
If the AF_XDP chunk size and desc->len are large (e.g. up to 65536 on systems
with 64KB pages), csum_start can be near 65535. When headroom (hr) is added,
the result could overflow the 16-bit skb->csum_start and be truncated.
If this truncates to a smaller value, skb_checksum_start_offset(skb) could
subtract the headroom and produce a negative offset. In skb_checksum_help(),
this negative offset would be implicitly cast to an unsigned integer,
evaluating to true in the offset >= skb_headlen(skb) check and triggering a
WARN_ONCE while dropping the packet.
Additionally, if hardware checksum offload is used, drivers might pass this
wrapped negative offset to the hardware, instructing it to perform DMA
accesses massively out-of-bounds from the packet buffer. Could this result
in IOMMU faults or memory corruption?
> + skb->csum_offset = csum_offset;
> skb->ip_summed = CHECKSUM_PARTIAL;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260520004244.55663-1-kerneljasonxing@gmail.com?part=1
next prev parent reply other threads:[~2026-05-30 0:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 0:42 [PATCH net v4 0/5] xsk: fix meta and publish of cq issues Jason Xing
2026-05-20 0:42 ` [PATCH net v4 1/5] xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata() Jason Xing
2026-05-21 12:04 ` Maciej Fijalkowski
2026-05-30 0:44 ` sashiko-bot [this message]
2026-05-20 0:42 ` [PATCH net v4 2/5] xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx Jason Xing
2026-05-21 12:05 ` Maciej Fijalkowski
2026-05-20 0:42 ` [PATCH net v4 3/5] xsk: drain continuation descs after overflow in xsk_build_skb() Jason Xing
2026-05-20 16:10 ` Maciej Fijalkowski
2026-05-20 23:53 ` Jason Xing
2026-05-21 12:02 ` Maciej Fijalkowski
2026-05-21 13:10 ` Jason Xing
2026-05-22 9:06 ` Magnus Karlsson
2026-05-22 9:22 ` Jason Xing
2026-05-30 0:44 ` sashiko-bot
2026-05-20 0:42 ` [PATCH net v4 4/5] xsk: drain continuation descs on invalid descriptor in __xsk_generic_xmit() Jason Xing
2026-05-30 0:44 ` sashiko-bot
2026-05-20 0:42 ` [PATCH net v4 5/5] selftests/xsk: drain CQ to wait for TX completion Jason Xing
2026-05-30 0:44 ` sashiko-bot
2026-05-21 12:23 ` [PATCH net v4 0/5] xsk: fix meta and publish of cq issues Maciej Fijalkowski
2026-05-21 12:41 ` Jason Xing
2026-05-21 12:59 ` Maciej Fijalkowski
2026-05-21 13:07 ` Jason Xing
2026-05-21 14:24 ` Maciej Fijalkowski
2026-05-22 8:55 ` Jason Xing
2026-05-22 13:48 ` Jason Xing
2026-05-22 18:33 ` Maciej Fijalkowski
2026-05-22 23:49 ` Jason Xing
2026-05-26 19:43 ` Maciej Fijalkowski
2026-05-26 23:26 ` Jason Xing
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=20260530004416.702751F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kerneljasonxing@gmail.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.