[PATCH 5.15] vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().

[PATCH 5.15] vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().

[Artem Novikov]

From: Kuniyuki Iwashima <kuniyu@google.com>

commit 30a45c0bffdd62350261e2f2689fdba426a33578 upstream.

udp_tunnel_sock_release() could set sk->sk_user_data to NULL
while vxlan_gro_prepare_receive() is running.

Let's check if rcu_dereference_sk_user_data() is NULL after
skb_gro_remcsum_init().

Fixes: 5602c48cf875 ("vxlan: change vxlan to use UDP socket GRO")
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260502031401.3557229-7-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ Artem Novikov: Apply the check to the older vxlan_gro_receive()
  implementation. Initialize the remcsum state first and use the
  existing out path for cleanup when sk_user_data has been cleared. ]
Signed-off-by: Artem Novikov <naa@amicon.ru>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
---
 drivers/net/vxlan/vxlan_core.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index a4e911386a..bb2896b18f 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -791,12 +791,16 @@ static struct sk_buff *vxlan_gro_receive(struct sock *sk,
 	struct vxlanhdr *vh, *vh2;
 	unsigned int hlen, off_vx;
 	int flush = 1;
-	struct vxlan_sock *vs = rcu_dereference_sk_user_data(sk);
+	struct vxlan_sock *vs;
 	__be32 flags;
 	struct gro_remcsum grc;
 
 	skb_gro_remcsum_init(&grc);
 
+	vs = rcu_dereference_sk_user_data(sk);
+	if (!vs)
+		goto out;
+
 	off_vx = skb_gro_offset(skb);
 	hlen = off_vx + sizeof(*vh);
 	vh   = skb_gro_header_fast(skb, off_vx);

Re: [PATCH 5.15] vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH 5.15] vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().

[Новиков Артём]

Hi,

Resending in plain text because the mailing lists rejected the
HTML version of my previous reply.

This is a 5.15 stable backport of Kuniyuki Iwashima's upstream
commit 30a45c0bffdd62350261e2f2689fdba426a33578.

The original submission does not specify how the bug was discovered.
A later report includes a KASAN diagnostic and a kernel panic.
Kuniyuki confirmed that the upstream commit above fixes that issue:
https://lists.openwall.net/netdev/2026/07/06/423

Validation of this backport covered patch application and formatting,
but did not include runtime reproduction on 5.15.

Best regards,
Artem Novikov


От: netdev-bot+sinfo@kernel.org <netdev-bot+sinfo@kernel.org>
Отправлено: 1 октября 2026 г. 16:39
Кому: Новиков Артём
Копия: stable@vger.kernel.org; Greg Kroah-Hartman; Sasha Levin; lvc-project@linuxtesting.org; Разов Роман; pchelkin@ispras.ru; David S. Miller; Jakub Kicinski; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Тема: Re: [PATCH 5.15] vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().
    
Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.