* [DPDK/other Bug 2005] GTP ptype parser out-of-bounds read
@ 2026-08-28 14:26 bugzilla
0 siblings, 0 replies; only message in thread
From: bugzilla @ 2026-08-28 14:26 UTC (permalink / raw)
To: dev
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: dev@dpdk.org
Reporter: thomas@monjalon.net
Target Milestone: ---
Group: security
Report date: 2026-06-02
Reported by: Borys Tsyrulnikov <tsyrulnikov.borys@gmail.com>
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: stable@dpdk.org ; regression author Jie Hai <haijie1@huawei.com>
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-08-28 14:26 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-28 14:26 [DPDK/other Bug 2005] GTP ptype parser out-of-bounds read bugzilla
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.