|SUCCESS| net: fix GTP Tunnel parse out-of-bounds read

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/162967

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-09

Reviewing patch: net: fix GTP Tunnel parse out-of-bounds read

sha: 64ed7f854cf4 ("net: add tunnel packet type parsing")
Author: Stephen Hemminger <stephen at networkplumber.org>
Subject: [PATCH] net: fix GTP Tunnel parse out-of-bounds read

This patch addresses an out-of-bounds read when parsing GTP packets that
are fragmented or contain only a GTP header without payload.

> diff --git a/lib/net/rte_net.c b/lib/net/rte_net.c
> index 458b4814a9..da4018437b 100644
> --- a/lib/net/rte_net.c
> +++ b/lib/net/rte_net.c
> @@ -219,8 +219,7 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
>  	case RTE_GTPU_UDP_PORT: {
>  		const struct rte_gtp_hdr *gh;
>  		struct rte_gtp_hdr gh_copy;
> -		uint8_t gtp_len;
> -		uint8_t ip_ver;
> +		uint32_t gtp_len;
>  		gh = rte_pktmbuf_read(m, *off, sizeof(*gh), &gh_copy);
>  		if (unlikely(gh == NULL))
>  			return 0;

Can the size of gtp_len overflow uint32_t? The calculation comes from the
GTP header which presumably has size constraints, but should this patch
verify the computed length doesn't exceed the packet buffer size before
using it to adjust the offset?

> @@ -231,9 +230,16 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
>  		 * Check message type. If message type is 0xff, it is
>  		 * a GTP data packet. If not, it is a GTP control packet
>  		 */
> +		*off += gtp_len;
>  		if (gh->msg_type == 0xff) {
> -			ip_ver = *(const uint8_t *)((const char *)gh + gtp_len);
> -			ip_ver = (ip_ver) & 0xf0;
> +			const uint8_t *l3_hdr;
> +			uint8_t l3_copy, ip_ver;
> +
> +			l3_hdr = rte_pktmbuf_read(m, *off, sizeof(*l3_hdr), &l3_copy);
> +			if (unlikely(l3_hdr == NULL))
> +				return 0;
> +
> +			ip_ver = *l3_hdr & 0xf0;

Does moving the offset update before the ip_ver check affect control
packet handling? When msg_type is not 0xff and the code takes the else
branch, the offset has been advanced by gtp_len even though no L3 header
was validated or read. Could this cause issues for subsequent parsing?

>  			if (ip_ver == RTE_GTP_TYPE_IPV4)
>  				*proto = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
>  			else if (ip_ver == RTE_GTP_TYPE_IPV6)
> @@ -243,7 +249,6 @@ ptype_tunnel_with_udp(uint16_t *proto, const struct rte_mbuf *m,
>  		} else {
>  			*proto = 0;
>  		}
> -		*off += gtp_len;
>  		hdr_lens->inner_l2_len = gtp_len + sizeof(struct rte_udp_hdr);
>  		hdr_lens->tunnel_len = gtp_len;

Does the ptype_tunnel_with_udp() function validate that *off does not
exceed the packet length before returning? If the offset update happens
before the validation and the function returns early due to NULL from
rte_pktmbuf_read(), has *off been left in an inconsistent state for the
caller?