All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kuniyuki Iwashima <kuniyu@google.com>
To: Eric Dumazet <edumazet@kernel.org>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>,
	Willem de Bruijn <willemb@google.com>,
	Simon Horman <horms@kernel.org>,
	 netdev@vger.kernel.org, Kyle Zeng <kylebot@openai.com>
Subject: Re: [PATCH net] net: require a full socket in sock_confirm_neigh()
Date: Thu, 5 Nov 2026 20:31:47 +0000	[thread overview]
Message-ID: <auznnQkMoeG7alUM@google.com> (raw)
In-Reply-To: <20261104132900.1071940-1-edumazet@kernel.org>

On Wed, 04 Nov 2026 14:29:00 +0100, Eric Dumazet wrote:
> From: Kyle Zeng <kylebot@openai.com>
> 
> An skb can retain dst_pending_confirm after its original output and
> socket owner have changed. For example, a raw MSG_CONFIRM packet can
> cross veth, have a TCP request socket assigned by TPROXY, and be bridged
> into gretap. Neighbor output for the outer packet then calls
> sock_confirm_neigh() with the request socket in skb->sk.
> 
> The helper unconditionally treats a non-NULL skb->sk as a full socket
> when accessing sk_dst_pending_confirm. TCP request and TIME_WAIT sockets
> do not contain that field. This produces an out-of-bounds four-byte read
> and, if the word is nonzero, an out-of-bounds four-byte zero write. A
> KASAN-enabled kernel reports:
> 
>   BUG: KASAN: slab-out-of-bounds in ip_finish_output2+0xc9f/0xd60
>   Read of size 4 at addr ffff8880bdc3d880 by task tproxy_dst_conf/1771
> 
> Require sk_fullsock() before accessing the socket field, moving the
> existing helper earlier in the header to make it available here. Keep
> neigh_confirm() independent of the socket type so the skb's neighbor
> confirmation still works, including for socketless packets. This also
> covers the IPv6, VRF, and BPF neighbor-output callers.
> 
> Fixes: 4ff0620354f2 ("net: add dst_pending_confirm flag to skbuff")
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> Signed-off-by: Eric Dumazet <edumazet@kernel.org>

Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>

  reply	other threads:[~2026-11-05 20:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 13:29 [PATCH net] net: require a full socket in sock_confirm_neigh() Eric Dumazet
2026-11-05 20:31 ` Kuniyuki Iwashima [this message]
2026-11-10  2:54 ` patchwork-bot+netdevbpf

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=auznnQkMoeG7alUM@google.com \
    --to=kuniyu@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kylebot@openai.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.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.