On Fri, Jul 03, 2026 at 04:42:44PM +0800, Zhixing Chen wrote:

GTPv1-U packets may carry a chain of extension headers before the inner IP packet. The receive path already parses and skips these extension headers, but it currently reads the inner protocol before doing so.

As a result, the first extension header byte is interpreted as the inner IP version. Packets with extension headers are then dropped before PDP lookup.

Parse the extension header chain before calling gtp_inner_proto(), so the inner protocol is read from the actual inner IP header.

Missing Fixes: tag.

Signed-off-by: Zhixing Chen running910@gmail.com

I noticed this while running a few GTP tunnel tests with a veth pair and a peer network namespace.

The commands below only set up a small GTPv1-U demo and verify that the plain tunnel works as expected:

ip link add vroot type veth peer name vpeer ip a a 172.0.0.1/24 dev vroot ip link set vroot up ip a a 172.99.0.1/32 dev lo gtp-link add gtp0 ip 172.0.0.1 & gtp-tunnel add gtp0 v1 200 100 172.99.0.2 172.0.0.2 ip r a 172.99.0.2/32 dev gtp0 ip link set gtp0 mtu 1500

ip netns add nspeer ip link set vpeer netns nspeer ip netns exec nspeer ip a a 172.0.0.2/24 dev vpeer ip netns exec nspeer ip link set vpeer up ip netns exec nspeer ip a a 172.99.0.2/32 dev lo ip netns exec nspeer ip link set lo up

ip netns exec nspeer gtp-link add gtp1 ip 172.0.0.2 & ip netns exec nspeer gtp-tunnel add gtp1 v1 100 200 172.99.0.1 172.0.0.1 ip netns exec nspeer ip r a 172.99.0.1/32 dev gtp1 ip netns exec nspeer ip link set gtp1 mtu 1500

With this setup, plain traffic between 172.99.0.1 and 172.99.0.2 goes through the GTP tunnel.

After that, I used a small sender in the peer namespace to build two UDP/2152 packets for the root namespace GTP endpoint. Both packets use TEID 200 and carry an inner UDP packet from 172.99.0.2:12345 to 172.99.0.1:9999. The first packet is a plain GTPv1-U T-PDU. The second packet carries the same inner UDP packet after a GTP extension header.

Before this fix, a receiver bound to 172.99.0.1:9999 only receives the plain packet:

root@vm:/# python gtp_nsroot_recv.py listening on 172.99.0.1:9999 received #1 from ('172.99.0.2', 12345): b'plain'

After this fix, it receives both packets:

root@vm:/# python gtp_nsroot_recv.py listening on 172.99.0.1:9999 received #1 from ('172.99.0.2', 12345): b'plain' received #2 from ('172.99.0.2', 12345): b'extension'

---

drivers/net/gtp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index a60ef32b35b8..4a8b00548673 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -826,6 +826,10 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb) if (!pskb_may_pull(skb, hdrlen)) return -1;

• if (gtp1->flags & GTP1_F_EXTHDR &&

•    gtp_parse_exthdrs(skb, &hdrlen) < 0)
  

• return -1;
  

• if (gtp_inner_proto(skb, hdrlen, &inner_proto) < 0) { netdev_dbg(gtp->dev, "GTP packet does not encapsulate an IP packet\n"); return -1;

@@ -840,10 +844,6 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb) return 1; }

• if (gtp1->flags & GTP1_F_EXTHDR &&

•    gtp_parse_exthdrs(skb, &hdrlen) < 0)
  

• return -1;
  

• return gtp_rx(pctx, skb, hdrlen, gtp->role, inner_proto);

}

-- 2.34.1