https://bugs.dpdk.org/show_bug.cgi?id=2005
Bug ID: 2005
Summary: GTP ptype parser out-of-bounds read
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: other
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Group: security
Report date: 2026-06-02
Reported by: Borys Tsyrulnikov <[email protected]>
Hello DPDK security team,
I'm reporting two memory-safety defects found by source audit of the
development branch (HEAD a53fd23, == origin/main at time of writing). One is
reproducible with an AddressSanitizer PoC; the other is source-verified. Fixes
for both are included inline below and attached as patches.
Credit: please credit me as "Borys Tsyrulnikov".
Embargo: No specific embargo requested from my side; please coordinate
according
to the DPDK process if the issues qualify. I will not disclose publicly (PoC or
details) until you advise.
================================================================
Issue 1 — lib/net: out-of-bounds read in GTP packet-type parsing
================================================================
Severity: medium (remote DoS on hosts running the software ptype parser on
untrusted traffic). REPRODUCIBLE — AddressSanitizer PoC attached.
Location: lib/net/rte_net.c:235, function ptype_tunnel_with_udp(), GTP case.
Description:
The GTP case reads the inner IP-version byte at offset gtp_len (8, or 12 when
the E/S/PN flags are set) from the GTP header:
gh = rte_pktmbuf_read(m, *off, sizeof(*gh), &gh_copy); /*
validates 8 bytes */
...
if (gh->msg_type == 0xff)
ip_ver = *(const uint8_t *)((const char *)gh + gtp_len); /*
reads byte 8 or 12 */
rte_pktmbuf_read() only guarantees sizeof(struct rte_gtp_hdr) == 8 bytes. The
read at gh[gtp_len] is past that, with no further bounds check. When the 8 GTP
bytes are not contiguous in the first mbuf segment, rte_pktmbuf_read() returns
the 8-byte on-stack copy gh_copy, so gh[gtp_len] is an out-of-bounds read past
that stack object.
Reachability / attacker model:
rte_net_get_ptype(m, &lens, RTE_PTYPE_ALL_MASK) runs on received,
attacker-controlled packets — notably lib/vhost/virtio_net.c:2800 (the host
parsing packets from a guest VM), plus virtio/vhost/tap/netvsc RX. A malicious
guest can craft a GTP packet with E/S/PN set and split across mbuf segments to
force the stack-copy path and trigger the over-read.
Reproduction (attached poc_gtp_oob.c + asan_crash.sanitized.txt, against an
ASan
DPDK build):
READ of size 1 ... ptype_tunnel_with_udp ../lib/net/rte_net.c:235
[64, 72) 'gh_copy' <== access at offset 76 overflows this variable
Fix (attached patch-02-net-gtp-ptype.patch):
Read the version byte through the bounds-checked accessor and treat a short
packet as unknown inner protocol:
+ const uint8_t *ver;
...
- ip_ver = *(const uint8_t *)((const char *)gh + gtp_len);
- ip_ver = (ip_ver) & 0xf0;
+ ver = rte_pktmbuf_read(m, *off + gtp_len, sizeof(ip_ver), &ip_ver);
+ ip_ver = (ver == NULL) ? 0 : (*ver & 0xf0);
Patch commit-message tags (for the eventual fix; NOT recipients of this email):
Fixes: 64ed7f854cf4 ("net: add tunnel packet type parsing") [in v25.03+]
Cc: [email protected] ; regression author Jie Hai <[email protected]>
--
You are receiving this mail because:
You are the assignee for the bug.
