From: Steffen Klassert <steffen.klassert@secunet.com>
To: Fourie Zhang <littleddfu@gmail.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, Zhiling Zou <zhilinz@nebusec.ai>,
TencentOS Corvus AI <corvus@tencent.com>,
<netdev@vger.kernel.org>, Fourie Zhang <fouriezhang@tencent.com>,
<stable@vger.kernel.org>
Subject: Re: [PATCH ipsec v2] xfrm4: use a full socket for local errors
Date: Fri, 30 Oct 2026 09:36:22 +0000 [thread overview]
Message-ID: <auRlFmn9TurvAhcS@gauss4> (raw)
In-Reply-To: <20261022022627.4132880-1-littleddfu@gmail.com>
On Thu, Oct 22, 2026 at 10:26:22AM +0800, Fourie Zhang wrote:
> From: Fourie Zhang <fouriezhang@tencent.com>
>
> xfrm4_local_error() passes skb->sk to inet_sk() and ip_local_error()
> without ensuring it points to a full socket. TCP SYN-ACK skbs can be owned
> by TCP_NEW_SYN_RECV request sockets.
>
> xfrm4_tunnel_check_size() already checks sk_fullsock() since commit
> 1620c88887b1 ("xfrm: Fix the usage of skb->sk"), so iptfs_is_too_big() is
> the only remaining IPv4 caller passing a request socket here: the sk it
> tests is the listener, while skb->sk is the request socket.
>
> When IP-TFS rejects such an skb because it exceeds its payload MTU, the
> local error path treats the request socket as a struct inet_sock. KASAN
> reports a slab-out-of-bounds read in ip_local_error() beyond the
> request_sock_TCP allocation.
>
> Resolve the skb owner with skb_to_full_sk() before accessing inet_sock
> state or reporting the error. This maps a request socket to its listener
> and rejects sockets that cannot be used as full sockets, matching what
> commit 6973a21ee73c ("ipv6: xfrm: use full sockets in local error paths")
> did for xfrm6_local_error().
>
> Fixes: 0e4fbf013fa5 ("xfrm: iptfs: add user packet (tunnel ingress) handling")
> Cc: stable@vger.kernel.org
> Reported-by: TencentOS Corvus AI <corvus@tencent.com>
> Link: https://lore.kernel.org/netdev/20260908224856.1591189-1-kuba@kernel.org/
> Reviewed-by: Eric Dumazet <edumazet@kernel.org>
> Assisted-by: tencentos-corvus-ai:hy4-preview
> Signed-off-by: Fourie Zhang <fouriezhang@tencent.com>
Applied, thanks a lot!
prev parent reply other threads:[~2026-10-30 7:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 2:26 [PATCH ipsec v2] xfrm4: use a full socket for local errors Fourie Zhang
2026-10-30 9:36 ` Steffen Klassert [this message]
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=auRlFmn9TurvAhcS@gauss4 \
--to=steffen.klassert@secunet.com \
--cc=corvus@tencent.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=fouriezhang@tencent.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=littleddfu@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=zhilinz@nebusec.ai \
/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.