kernel/linux.git/drivers/net/vxlan, branch v7.2-rc1

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-06-04T22:29:04+00:00

Cross-merge networking fixes after downstream PR (net-7.1-rc7). Silent conflicts: net/wireless/nl80211.c cb9959ab5f99 ("wifi: cfg80211: enforce HE/EHT cap/oper consistency") a384ae969902 ("wifi: cfg80211: move AP HT/VHT/... operation to beacon info") https://lore.kernel.org/aiGJDaHV4UlCexIQ@sirena.org.uk Conflicts: drivers/net/wireless/intel/iwlwifi/mld/ap.c a342c99cb70d ("wifi: iwlwifi: mld: honor BSS_CHANGED_BEACON_ENABLED") 9bf1b409afc7 ("wifi: iwlwifi: mld: send tx power constraints before link activation") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk drivers/net/wireless/intel/iwlwifi/pcie/drv.c 093305d801fa ("wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used") e2323929a68a ("wifi: iwlwifi: pcie: add debug print for resume flow if powered off") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk Adjacent changes: drivers/net/ethernet/airoha/airoha_eth.c b38cae85d1c4 ("net: airoha: Fix use-after-free in metadata dst teardown") ec6c391bcca7 ("net: airoha: Introduce airoha_gdm_dev struct") drivers/net/ethernet/microchip/lan743x_main.c 8173d22b211f ("net: lan743x: permit VLAN-tagged packets up to configured MTU") e3c6508a46f5 ("net: lan743x: avoid netdev-based logging before netdev registration") Signed-off-by: Jakub Kicinski

vxlan: vnifilter: fix spurious notification on VNI update

2026-06-04T15:47:45+00:00

When a VNI is re-added with the same attributes (e.g. same group or no group), vxlan_vni_update() sends a spurious RTM_NEWTUNNEL notification even though nothing changed. The bug is that 'if (changed)' tests whether the pointer is non-NULL, not the bool value it points to. Since every caller passes a valid pointer, the condition is always true and the notification fires unconditionally. Fix by dereferencing the pointer: 'if (*changed)'. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # bridge vni add vni 1000 dev vxlan100 # spurious notification Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Signed-off-by: Andy Roulin Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260602185138.253265-3-aroulin@nvidia.com Signed-off-by: Jakub Kicinski

vxlan: vnifilter: send notification on VNI add

2026-06-04T15:47:45+00:00

When a new VNI is added to a vxlan device with vnifilter enabled, no RTM_NEWTUNNEL notification is sent to userspace. This means 'bridge monitor vni' never shows VNI add events, even though VNI delete events are reported correctly. The bug is in vxlan_vni_add(), where the notification is guarded by 'if (changed)'. The 'changed' flag is set by vxlan_vni_update_group() only when the multicast group or remote IP is modified, but for a new VNI added without a group (e.g. in L3 VxLAN interface scenarios), the function returns early without setting changed=true. Since this is a new VNI, the notification should be sent unconditionally. The notification is not guarded by the return value of vxlan_vni_update_group() because, at this point, the VNI has already been inserted into the hash table and list with no rollback on error. The VNI will be visible in 'bridge vni show' regardless, so userspace should be informed. This is consistent with vxlan_vni_del() which also notifies unconditionally. The 'if (changed)' guard remains correct in vxlan_vni_update(), which handles the case where a VNI already exists and is being re-added -- there, we only want to notify if the group/remote actually changed. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # no notification # bridge vni delete vni 1000 dev vxlan100 # notification received Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Reported-by: Chirag Shah Signed-off-by: Andy Roulin Reviewed-by: Petr Machata Link: https://patch.msgid.link/20260602185138.253265-2-aroulin@nvidia.com Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-05-28T21:02:21+00:00

Cross-merge networking fixes after downstream PR (net-7.1-rc6). Conflicts: drivers/net/phy/air_en8811h.c d895767c33781 ("net: phy: air_en8811h: add AN8811HB MCU assert/deassert support") dddfadd75197e ("net: phy: Add Airoha phy library for shared code") 5226bb6634cdf ("net: phy: air_phy_lib: Factorize BuckPBus register accessors") e08f0ea6daf2e ("net: phy: Rename Airoha common BuckPBus register accessors") net/sched/sch_netem.c a2f6ed7b4873 ("net/sched: netem: add per-impairment extended statistics") 9552b11e3eda ("net/sched: fix packet loop on netem when duplicate is on") Adjacent changes: drivers/dpll/zl3073x/core.c c1224569cef0 ("dpll: zl3073x: make frequency monitor a per-device attribute") 54e65df8cf18 ("dpll: zl3073x: report FFO as DPLL vs input reference offset") net/iucv/af_iucv.c 347fdd4df85f ("af_iucv: convert to getsockopt_iter") 3589d20a666c ("net/iucv: fix locking in .getsockopt") Signed-off-by: Jakub Kicinski

vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()

2026-05-27T01:10:55+00:00

skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko. Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") Signed-off-by: Eric Dumazet Reviewed-by: Stefano Brivio Link: https://patch.msgid.link/20260525203642.2389723-1-edumazet@google.com Signed-off-by: Jakub Kicinski

vxlan: Remove synchronize_net() in vxlan_sock_release().

2026-05-21T02:12:29+00:00

Initially, a dedicated workqueue was used to defer calling udp_tunnel_sock_release(vxlan_sock->sock) and kfree(vxlan_sock). Later, commit 0412bd931f5f ("vxlan: synchronously and race-free destruction of vxlan sockets") removed the workqueue and instead invoked these two functions immediately after synchronize_net(). This was intended to prevent UAF of the UDP socket in the fast path. ( Note that the "nondeterministic behaviour" mentioned in that commit was not addressed, as another thread not waiting RCU gp still sees the same behaviour. ) However, a week prior to that change, commit ca065d0cf80f ("udp: no longer use SLAB_DESTROY_BY_RCU") had already moved UDP socket freeing to after the RCU grace period. This made the synchronize_net() in vxlan_sock_release() completely redundant. Since vxlan_sock now uses kfree_rcu() and is invoked after udp_tunnel_sock_release(), vxlan_sock is guaranteed to be freed either at the same time or after the UDP socket is released, following the RCU grace period. Let's remove the redundant synchronize_net() in vxlan_sock_release(). Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260518050726.318824-2-kuniyu@google.com Signed-off-by: Jakub Kicinski

vxlan: Free vxlan_sock with kfree_rcu().

2026-05-06T00:47:05+00:00

We will remove synchronize_rcu() in udp_tunnel_sock_release(). We must ensure that vxlan_sock is freed after inflight RX fast path. Let's free vxlan_sock with kfree_rcu(). Note that vxlan_sock.vni_list[] is 8K and struct rcu_head must be placed before it. Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260502031401.3557229-9-kuniyu@google.com Signed-off-by: Jakub Kicinski

vxlan: Store struct sock in struct vxlan_sock.

2026-05-06T00:47:04+00:00

Commit 3cf7203ca620 ("net/tunnel: wait until all sk_user_data reader finish before releasing the sock") added synchronize_rcu() in udp_tunnel_sock_release(). This was intended to protect the fast path of a dying vxlan device from dereferencing vxlan_sock->sock->sk after sock_orphan() has set sock->sk to NULL. However, vxlan does not need to access struct socket itself in the fast path; it only reads struct sock, and struct socket is only used for tunnel setup and teardown. Let's store struct sock directly in struct vxlan_sock. In the next patch, we will free vxlan_sock with kfree_rcu(), then vxlan no longer needs synchronize_rcu() in udp_tunnel_sock_release(). Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260502031401.3557229-8-kuniyu@google.com Signed-off-by: Jakub Kicinski

vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().

2026-05-06T00:47:04+00:00

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 Link: https://patch.msgid.link/20260502031401.3557229-7-kuniyu@google.com Signed-off-by: Jakub Kicinski

udp_tunnel: Pass struct sock to udp_tunnel_notify_{add,del}_rx_port().

2026-05-06T00:47:04+00:00

None of the udp_tunnel users need struct socket in their fast paths; it is only used for tunnel setup / teardown. Even udp_tunnel_notify_{add,del}_rx_port() do not need struct socket. Let's change udp_tunnel_notify_{add,del}_rx_port() to take struct sock instead of struct socket. Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260502031401.3557229-6-kuniyu@google.com Signed-off-by: Jakub Kicinski