[PATCH net] gtp: parse extension headers before reading inner protocol

[PATCH net] gtp: parse extension headers before reading inner protocol

[Zhixing Chen]

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.

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

Re: [PATCH net] gtp: parse extension headers before reading inner protocol

[Pablo Neira Ayuso]

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
> 

Re: [PATCH net] gtp: parse extension headers before reading inner protocol

[Zhixing Chen]

> Missing Fixes: tag.

Thanks for pointing this out. I have sent v2 with the Fixes tag added.