From: Qihang <q.h.hack.winter@gmail.com>
To: netdev@vger.kernel.org
Cc: steffen.klassert@secunet.com, herbert@gondor.apana.org.au,
stable@vger.kernel.org, kuba@kernel.org
Subject: [PATCH net v2] xfrm: validate ihl in xfrm4_transport_output()
Date: Wed, 23 Sep 2026 10:16:40 +0800 [thread overview]
Message-ID: <20260923021640.38855-1-q.h.hack.winter@gmail.com> (raw)
In-Reply-To: <20260917072226.80788-1-q.h.hack.winter@gmail.com>
xfrm4_transport_output() reads the IPv4 header length (ihl) from the
packet and uses it for __skb_pull() and memmove() without validating it,
so a frame with ihl * 4 larger than the linear header underflows skb->len
to a huge value or trips BUG() in __skb_pull().
Packets injected into an xfrm interface (e.g. AF_PACKET on an xfrmi
device) reach xfrm output without the header validation that
ip_rcv_core() applies to received traffic. The underflowed length then
flows into esp_output() and the crypto scatterlist setup, where every
length in the underflow window ends in a fatal fault (BUG_ON in
__skb_to_sgvec()). This is a deterministic local denial of service
reachable by an unprivileged user through a user and network namespace.
Reject ihl < 5, matching ip_rcv_core(), so a complete IPv4 header is
present. Then use pskb_may_pull() to make the header linear: this
rejects ihl > skb->len, linearizes a header that currently lives in
fragments, and guarantees __skb_pull()'s precondition that the pull must
not drive skb->len below skb->data_len, and it keeps the memmove() source
in bounds. ip_hdr() is re-read afterwards because pskb_may_pull() may
reallocate the skb head. xfrm6_transport_output() already bounds its
header length through xfrm6_hdr_offset().
Fixes: b59f45d0b2878 ("[IPSEC] xfrm: Abstract out encapsulation modes")
Cc: stable@vger.kernel.org
Signed-off-by: Qihang <q.h.hack.winter@gmail.com>
---
net/xfrm/xfrm_output.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index e305ba3..86943e2 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -66,6 +66,11 @@ static int xfrm4_transport_output(struct xfrm_state *x, struct sk_buff *skb)
struct iphdr *iph = ip_hdr(skb);
int ihl = iph->ihl * 4;
+ if (iph->ihl < 5 || !pskb_may_pull(skb, ihl))
+ return -EINVAL;
+
+ iph = ip_hdr(skb);
+
if (!skb->inner_protocol)
skb_set_inner_transport_header(skb,
skb_transport_offset(skb));
--
2.46.0
next prev parent reply other threads:[~2026-09-23 2:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 7:22 [PATCH] xfrm: validate ihl in xfrm4_transport_output() Qihang
2026-09-21 7:52 ` netdev-bot+sashiko
2026-09-23 2:16 ` Qihang
2026-09-23 2:16 ` Qihang [this message]
2026-09-23 2:24 ` [PATCH net v2] " Herbert Xu
2026-09-23 3:28 ` Qihang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260923021640.38855-1-q.h.hack.winter@gmail.com \
--to=q.h.hack.winter@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.