linux-stable.git/drivers/net, branch v7.2

wifi: mt76: mt7921: refactor regd update to fix recursive mutex deadlock

2026-08-16T18:07:18+00:00

Split mt7921_mcu_regd_update() into two functions to prevent recursive
mutex acquisition. Introduce __mt7921_mcu_regd_update() as the internal
implementation that assumes the mutex is already held by the caller,
while mt7921_mcu_regd_update() remains as the external interface that
handles mutex acquisition and release.

This fixes a deadlock issue when mt7921_regd_set_6ghz_power_type() is
called with the device mutex already held. Without this change, calling
mt7921_mcu_regd_update() would attempt to acquire the same mutex again,
causing a recursive lock deadlock.

The __mt7921_mcu_regd_update() function can be safely called when the
caller has already acquired the device mutex, avoiding the deadlock
while maintaining proper synchronization for regulatory domain updates.

Fixes: dc2608cf5224 ("wifi: mt76: mt7921: refactor regulatory notifier flow")
Signed-off-by: Charlie-cy Wu 
Tested-by: Mikhail Gavrilov 
Tested-by: Devin Wittmayer 
Signed-off-by: Linus Torvalds

Revert "wifi: mt76: Disable napi when removing device"

2026-08-13T16:00:55+00:00

This reverts commit 13b7e6a96a005c656d38f3da51581deaf9866375.

That commit made mt76_dma_cleanup() disable every RX NAPI instance before
deleting it, to silence WARNs in __netif_napi_del_locked() and
page_pool_disable_direct_recycling() seen when unloading mt7915e with an
MT7916.

On mt7921e and mt7925e the same instances are already disabled earlier,
in mt7921e_unregister_device() and mt7925e_unregister_device(), which
only afterwards call mt792x_dma_cleanup() -> mt76_dma_cleanup().  Each
instance is therefore disabled twice, and napi_disable() is not
idempotent: on return it leaves NAPIF_STATE_SCHED and NAPIF_STATE_NPSVC
set, so the second call spins in usleep_range() forever, waiting for bits
that nobody will clear.

mt7921_pci_shutdown() and mt7925_pci_shutdown() reuse the remove path, so
this is hit on every reboot, poweroff and module unload.  It is silent:
the stuck task keeps sleeping and rescheduling, so neither the hung task
detector nor the lockup detectors fire, and the last line on the console
is "systemd-shutdown[1]: Rebooting."

  task:modprobe        state:D stack:25720 pid:7954  tgid:7954
  Call Trace:
   
   __schedule+0x11b8/0x26d0
   schedule+0xe7/0x2f0
   schedule_hrtimeout_range_clock+0x218/0x330
   usleep_range_state+0x133/0x1b0
   napi_disable_locked+0x37d/0x5f0
   napi_disable+0x43/0x80
   mt76_dma_cleanup+0x2b4/0x860 [mt76]
   mt7921_pci_remove+0x17f/0x350 [mt7921e]
   pci_device_remove+0xb6/0x1e0
   device_release_driver_internal+0x38d/0x540
   driver_detach+0xd0/0x1b0
   bus_remove_driver+0x127/0x2d0
   pci_unregister_driver+0x2a/0x280
   __do_sys_delete_module+0x36a/0x5b0
   do_syscall_64+0x11c/0x6d0
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
   

Dropping the two driver-side loops instead was tried and rejected: with
them gone, the RX poll can reach mt76_token_release() via
PKT_TYPE_TXRX_NOTIFY and mt7921_mac_tx_free() while
mt76_connac2_tx_token_put() is running idr_destroy(&dev->token) outside
token_lock, which is a use-after-free rather than a hang [1].

Revert for now, so that reboot, poweroff and module unload work again.
The WARNs on mt7915e are a less severe problem than an unbootable
machine, and fixing them belongs in the drivers that delete the NAPI
instances, where each one can pick a point that is safe for its own
teardown order, rather than in the shared mt76_dma_cleanup().

[ This is the "landing soonish" known regression fix mentioned in the
  previous networking merge commit       - Linus ]

Reported-by: Bert Karwatzki 
Closes: https://lore.kernel.org/all/20260724151419.26014-1-spasswolf@web.de/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221818
Link: https://lore.kernel.org/all/20260730050428.GA73812@sol/ [1]
Signed-off-by: Mikhail Gavrilov 
Acked-by: Nicolas Cavallari 
Fixes: 13b7e6a96a00 ("wifi: mt76: Disable napi when removing device")
Tested-by: Devin Wittmayer 
Signed-off-by: Linus Torvalds

Merge tag 'ovpn-net-20260809' of https://github.com/OpenVPN/ovpn-net-next

2026-08-13T01:09:18+00:00

Antonio Quartulli says:

====================
Included fixes:

* release key slot crypto transforms from a workqueue rather than an RCU
  callback, because crypto_free_aead() may sleep with async or hardware
  implementations
* run all deferred ovpn work on a module-owned workqueue and drain it on
  module exit, so no work item can still be executing module text after
  the module is unloaded
* finish crypto callback cleanup (key slot release and leftover skb)
  before dropping the peer reference that gates netdev unregistration
  and module removal
* avoid dereferencing a NULL key slot when userspace asks to kill a key
  that is not installed on the peer

* tag 'ovpn-net-20260809' of https://github.com/OpenVPN/ovpn-net-next:
  ovpn: defer key slot crypto freeing to workqueue
  ovpn: run deferred work on a module-owned workqueue
  ovpn: finish crypto callback cleanup before peer release
  ovpn: fix NULL dereference when killing missing key
====================

Reviewed-by: Simon Horman 
Link: https://patch.msgid.link/20260809212142.2249027-1-antonio@openvpn.net
Signed-off-by: Jakub Kicinski

net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG

2026-08-13T00:36:19+00:00

On the packet reception path, the ID of the MAC Port on which the packet
was received, is embedded in the RX DMA Descriptor's metadata. The ID is
extracted using the helper function cppi5_desc_get_tags_ids() which fills
in the 16-bit Source Tag into the 'port_id' variable. However, it is only
the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID,
while the upper 8-bits are Hardware-Reserved and carry an arbitrary value.
With the existing logic, sporadic kernel crash is observed due to the
subsequent driver code accessing out-of-bound memory because of an invalid
port_id.

Hence, fix the port_id extraction logic to use only the lower 8-bits of the
Source Tag as the MAC Port ID.

Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
Signed-off-by: Siddharth Vadapalli 
Reviewed-by: Chintan Vankar 
Reviewed-by: Simon Horman 
Link: https://patch.msgid.link/20260807111738.2055900-1-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski

gve: fix NULL dereference due to missing ptp adjfine

2026-08-12T01:26:04+00:00

Fix NULL dereference due to missing implementation of adjfine, which can
be triggered from usermode as follows:

sudo ./testptp -d /dev/ptp0 -f 0
[  551.943697] BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
[  552.061946] Call Trace:
[  552.064487]  
[  552.066681]  ptp_clock_adjtime+0x1c0/0x2c0
[  552.070874]  ? get_clock_desc+0x6b/0xb0
[  552.074825]  pc_clock_adjtime+0x78/0xc0
[  552.078755]  __do_sys_clock_adjtime+0x85/0x110
[  552.083293]  do_syscall_64+0xea/0x610

Cc: stable@vger.kernel.org
Fixes: acd16380523b ("gve: Add initial PTP device support")
Signed-off-by: Jordan Rhee 
Signed-off-by: Harshitha Ramamurthy 
Reviewed-by: Vadim Fedorenko 
Link: https://patch.msgid.link/20260807224315.234152-3-hramamurthy@google.com
Signed-off-by: Jakub Kicinski

gve: fix zero-length skb frag with header-split

2026-08-12T01:26:04+00:00

When header split is enabled and a header-only packet is
received such as a pure TCP ACK, GVE will indicate an
RX SKB with a zero-length fragment. If this SKB is then
hairpinned and sent back out, the GVE TX path will emit
a zero-length descriptor. Hardware considers this
an illegal descriptor and stops the queue, causing a
TX timeout and interface reset.

Fix it by not adding the zero-length skb frag.

Cc: stable@vger.kernel.org
Fixes: 5e37d8254e7f ("gve: Add header split data path")
Suggested-by: Praveen Kaligineedi 
Co-developed-by: Ziwei Xiao 
Signed-off-by: Ziwei Xiao 
Signed-off-by: Jordan Rhee 
Signed-off-by: Harshitha Ramamurthy 
Link: https://patch.msgid.link/20260807224315.234152-2-hramamurthy@google.com
Signed-off-by: Jakub Kicinski

net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling

2026-08-11T11:25:03+00:00

In non-MSI-X mode (such as legacy INTx or single MSI), wx->msix_entry is
not allocated or initialized. Calling NGBE_INTR_MISC(wx) dereferences
wx->msix_entry->entry, leading to a NULL pointer dereference crash.

This issue was introduced by fixing the IRQ vector when the number of
VFs is 7. Fix the issue by explicitly checking `pdev->msix_enabled` to
determine the correct vector index.

Additionally, as a side fix, set the interrupt mask to BIT(0) for the
non-MSI-X fallback. In MSI/INTx mode, the MISC and queue interrupts
share vector 0, and the WX_PX_MISC_IVAR register is only valid in the
MSI-X case. Thus, BIT(0) is the correct mask for the miscellaneous cause
when MSI-X is disabled.

Fixes: 4174c0c331a2 ("net: ngbe: specify IRQ vector when the number of VFs is 7")
Signed-off-by: Jiawen Wu 
Reviewed-by: Breno Leitao 
Reviewed-by: Simon Horman 
Link: https://patch.msgid.link/B2693E9A8BFAD110+20260807062214.410838-1-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni

net: tap: fix wrong transport_header when sending VLAN-tagged frame

2026-08-11T11:14:00+00:00

In tap_get_user_xdp(), when processing a VLAN-tagged frame (e.g.
ETH_P_8021Q), skb_set_network_header() is called first to advance
network_header past the VLAN tag to the inner protocol header.
skb_probe_transport_header() is then called with skb->protocol still
set to ETH_P_8021Q, while nhoff (derived from skb_network_offset())
already points past the VLAN tag to the inner protocol header.

In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff
points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it
reads a struct vlan_hdr at the current nhoff via __skb_header_pointer(),
but that offset contains the inner protocol header (e.g. an IP header).
The bytes are misinterpreted as a VLAN header, yielding a garbage
encapsulated EtherType that matches no known protocol. The dissector
returns false, so skb_probe_transport_header() never calls
skb_set_transport_header(), leaving transport_header at its uninitialized
sentinel value (~0U).

Move skb_set_network_header() to after skb_probe_transport_header(). At
the time skb_probe_transport_header() is called, network_header still
points to the VLAN header (offset ETH_HLEN), so nhoff is correct and the
flow dissector can parse the VLAN header, extract the inner EtherType,
and advance nhoff to the inner protocol header, allowing transport_header
to be set correctly.

Fixes: 8c76e77f9069 ("tap: call skb_probe_transport_header after setting skb->dev")
Assisted-by: WChat:claude-opus-4-8
Signed-off-by: Wei Fang 
Reviewed-by: Willem de Bruijn 
Link: https://patch.msgid.link/20260807063405.688780-3-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni

vxlan: do not arm the ageing timer on a device that is down

2026-08-11T09:42:52+00:00

vxlan_changelink() arms vxlan->age_timer whenever the requested ageing
interval differs from the configured one:

	if (conf.age_interval != vxlan->cfg.age_interval)
		mod_timer(&vxlan->age_timer, jiffies);

There is no netif_running() test, so the timer is armed even on a device
that was never brought up.  The only synchronous cancel in the driver is
the timer_delete_sync() in vxlan_stop(), which is .ndo_stop.
netif_close_many() drops devices without IFF_UP before
__dev_close_many() runs, so that cancel is skipped for such a device.

vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a
member of struct vxlan_dev, so free_netdev() releases the allocation the
timer lives in while it is still queued on a timer_base.
expire_timers() unlinks the entry before it loads timer->function, so
the timer core writes through the freed object's list pointers:

  BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654
  Write of size 8 at addr ffff00001adace68 by task true/192
   __asan_store8+0x84/0xac
   __run_timers+0x208/0x654
   run_timer_softirq+0x154/0x18c
  Allocated by task 189:
   alloc_netdev_mqs+0x64/0x720
   rtnl_create_link+0x4ac/0x520
   rtnl_newlink+0x758/0xd00
  Freed by task 191:
   netdev_release+0x40/0x58
   netdev_run_todo+0x4a4/0x8c0
   rtnl_dellink+0x200/0x4e8

The rtnl operations involved are netns-scoped, so an unprivileged user
can perform them in a new user and network namespace.

Arming the timer on a down device never had an effect: vxlan_cleanup()
returns early on !netif_running(), and vxlan_open() arms the timer for
any non-zero interval once the device is brought up.  Add the missing
test.

Discovered by XBOW, triaged by Baul Lee 

Fixes: 40051c4dcad5 ("vxlan: Allow changing ageing time")
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee 
Reviewed-by: Ido Schimmel 
Link: https://patch.msgid.link/20260809111829.78834-1-baul.lee@xbow.com
Signed-off-by: Paolo Abeni

NTB: ntb_netdev: Preserve RX queue depth on allocation failure

2026-08-11T09:04:55+00:00

ntb_netdev_rx_handler() hands the received skb to the network stack
before allocating its replacement. If the allocation fails, nothing is
reposted. Every failure therefore takes one buffer out of the RX queue
while the interface remains up, and enough failures eventually stall
reception.

A retry path could refill the queue later, but ntb_netdev has none.
Allocate the replacement first instead. If that fails, drop the packet
and repost the same skb. This keeps the queue full and lets packet
delivery resume as soon as memory is available again.

Fixes: 548c237c0a99 ("net: Add support for NTB virtual ethernet device")
Cc: stable@vger.kernel.org
Signed-off-by: Koichiro Den 
Reviewed-by: Dave Jiang 
Link: https://patch.msgid.link/20260806032537.3526498-1-den@valinux.co.jp
Signed-off-by: Paolo Abeni