From: Stephen Hemminger <stephen@networkplumber.org>
To: Robin Jarry <rjarry@redhat.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH dpdk] net/tap: use offsets provided by rte_net_get_ptype
Date: Wed, 22 Apr 2026 09:32:15 -0700 [thread overview]
Message-ID: <20260422093215.001c1c00@phoenix.local> (raw)
In-Reply-To: <20260422133615.680318-2-rjarry@redhat.com>
On Wed, 22 Apr 2026 15:36:16 +0200
Robin Jarry <rjarry@redhat.com> wrote:
> Instead of guessing what are the proper header lengths, pass
> a rte_net_hdr_lens struct to rte_net_get_ptype and use it to get the
> proper header lengths/offsets in tap_verify_csum.
>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
> ---
AI review feedback spotted some things I didn't
On Wed, 22 Apr 2026 15:36:16 +0200
Robin Jarry <rjarry@redhat.com> wrote:
> Instead of guessing what are the proper header lengths, pass
> a rte_net_hdr_lens struct to rte_net_get_ptype and use it to get the
> proper header lengths/offsets in tap_verify_csum.
The two bounds checks this patch drops are not redundant with the new
l4_off check and need to stay in some form:
- if (l2_len + rte_be_to_cpu_16(iph->total_length) >
- rte_pktmbuf_data_len(mbuf))
- return;
...
- if (l2_len + l3_len + rte_be_to_cpu_16(iph->payload_len) >
- rte_pktmbuf_data_len(mbuf))
- return;
rte_ipv4_udptcp_cksum_verify() -> __rte_ipv4_udptcp_cksum() does:
l3_len = rte_be_to_cpu_16(ipv4_hdr->total_length);
...
l4_len = l3_len - ip_hdr_len;
cksum = rte_raw_cksum(l4_hdr, l4_len);
and the IPv6 variant reads payload_len the same way. Both are untrusted
values from the wire. Without the checks above, a packet whose
total_length / payload_len exceeds what was actually received causes
rte_raw_cksum() to read past the valid data - uninitialized tail room at
best, outside buf_len at worst. The IP/L4 CKSUM flags set on the mbuf
will then be computed over stale memory.
These checks were added deliberately in:
1168a4fd193 ("net/tap: add buffer overflow checks before checksum")
Please restore equivalent validation after rte_net_get_ptype(), e.g.
check iph->total_length (IPv4) and hdr_lens->l3_len + iph->payload_len
(IPv6) against rte_pktmbuf_data_len(mbuf) - hdr_lens->l2_len before
calling the checksum verifier.
One other thing: rte_net_get_ptype() returns RTE_PTYPE_L3_IPV6_EXT when
IPv6 extensions are present. The new "else if (l3 != RTE_PTYPE_L3_IPV6)"
clause falls through to return without setting any CKSUM flag for that
case. That matches pre-patch behavior, but the comment the patch removed
was the only thing documenting it. Either accept IPv6_EXT here (l3_len
now spans the extensions, so the existing helpers work as long as the
next header is TCP/UDP) or keep the comment.
Nit: the memset(&hdr_lens, 0, ...) runs on every Rx packet even when
RX_OFFLOAD_CHECKSUM is disabled. Moving it plus the &hdr_lens argument
inside the offload branch (passing NULL otherwise) avoids that.
I prefer initialization instead of memset, less error prone and easier.
next prev parent reply other threads:[~2026-04-22 16:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 13:36 [PATCH dpdk] net/tap: use offsets provided by rte_net_get_ptype Robin Jarry
2026-04-22 16:32 ` Stephen Hemminger [this message]
2026-04-27 10:41 ` [PATCH dpdk v2] " Robin Jarry
2026-04-28 13:36 ` Stephen Hemminger
2026-04-30 23:28 ` [PATCH dpdk v3] " Robin Jarry
2026-05-03 3:29 ` Stephen Hemminger
2026-05-12 15:16 ` [PATCH dpdk v4] " Robin Jarry
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=20260422093215.001c1c00@phoenix.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=rjarry@redhat.com \
/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.