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

[PATCH net v3] 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.

Fixes: c75fc0b9e5be ("gtp: identify tunnel via GTP device + GTP version + TEID + family")
Signed-off-by: Zhixing Chen <running910@gmail.com>
---

Changes in v3:
- Refetch the GTP header after pskb_may_pull() before checking the
  extension-header flag.

Changes in v2:
- Add missing Fixes tag.

v2: https://lore.kernel.org/netdev/20260703093708.18141-1-running910@gmail.com/T/ 
v1: https://lore.kernel.org/netdev/20260703084244.59077-1-running910@gmail.com/T/

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

diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index a60ef32b35b8..c0e38878af51 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -826,13 +826,17 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb)
 	if (!pskb_may_pull(skb, hdrlen))
 		return -1;
 
+	gtp1 = (struct gtp1_header *)(skb->data + sizeof(struct udphdr));
+
+	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;
 	}
 
-	gtp1 = (struct gtp1_header *)(skb->data + sizeof(struct udphdr));
-
 	pctx = gtp1_pdp_find(gtp, ntohl(gtp1->tid),
 			     gtp_proto_to_family(inner_proto));
 	if (!pctx) {
@@ -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 v3] gtp: parse extension headers before reading inner protocol

[Zhixing Chen]

Hi Pablo,

Gentle ping on this v3, in case it fell through the cracks.

It refetches the GTP header after pskb_may_pull() before checking the
extension-header flag, as you pointed out on v2.

Thanks,
Zhixing

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

[Paolo Abeni]

On 7/20/26 9:28 AM, Zhixing Chen wrote:
> Gentle ping on this v3, in case it fell through the cracks.

Please, don't.

Maintainers are overflown by LLM generated contents, and conferences &&
season interruption reduce the available time. While the patch is alive
in PW and no comments from reviewer and/or sashiko are pending, no
additional action is needed.

The patch LGTM, I'm applying it now.

/P

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

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Wed,  8 Jul 2026 12:22:44 +0800 you 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.
> 
> [...]

Here is the summary with links:
  - [net,v3] gtp: parse extension headers before reading inner protocol
    https://git.kernel.org/netdev/net/c/96e37e2f618e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

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

[Zhixing Chen]

> season interruption reduce the available time. While the patch is alive
> in PW and no comments from reviewer and/or sashiko are pending, no
> additional action is needed.

Thanks Pablo, understood. I just learned this workflow and will keep it in
mind next time.

I appreciate your review and help.

Best regards,
Zhixing