linux-stable.git/drivers/net, branch v7.2.3 Linux kernel stable tree wifi: mt76: mt7925: ensure tx headroom in usb_sdio_tx_prepare_skb 2026-09-02T12:33:21+00:00 Devin Wittmayer lucid_duck@justthetip.ca 2026-07-15T02:33:48+00:00 e5e8fc11a7ac578f16079f855b7fffc1649d053c commit ef3e34874d2332d0f63e72c2c35ce5c93568c125 upstream. mt7925_usb_sdio_tx_prepare_skb() pushes a TX descriptor and a USB header onto every skb and assumes the headroom for them is already there. That holds for locally generated traffic, where mac80211 reserves hw->extra_tx_headroom, but forwarded frames are sent through ieee80211_8023_xmit(), which does not reserve it. Bridge a wired interface to an mt7925u AP and the first forwarded frame that arrives short panics the kernel: skbuff: skb_under_panic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1 kernel BUG at net/core/skbuff.c:212! Call trace: skb_panic+0x58/0x60 (P) skb_push+0x58/0x60 mt7925_usb_sdio_tx_prepare_skb+0xf8/0x1b8 [mt7925_common] mt76u_tx_queue_skb+0xa0/0x1f8 [mt76_usb] __mt76_tx_queue_skb+0x54/0xe8 [mt76] mt76_txq_schedule.part.0+0x204/0x478 [mt76] mt76_txq_schedule_all+0x50/0x80 [mt76] mt792x_tx_worker+0x68/0x100 [mt792x_lib] __mt76_worker_fn+0x84/0x150 [mt76] Whether a given setup hits it depends on how much headroom the ingress netdev leaves in its rx skbs. Reproduced on a Raspberry Pi 5 bridging onboard ethernet to a Netgear A9000; originally reported on an MT7986 router running OpenWrt. Nick Morrow's testing on a Pi 4 (bcmgenet), which leaves more headroom, helped narrow the trigger to the ingress path. The same bug was fixed on mt7921 by commit 98c4d0abf5c4 ("mt76: mt7921: don't assume adequate headroom for SDIO headers"), but mt7925 was copied from mt7921 without the fix. Add the same guard here. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Cc: stable@vger.kernel.org Link: https://github.com/morrownr/mt76/issues/52 Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca> Link: https://patch.msgid.link/20260715023348.59506-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ef3e34874d2332d0f63e72c2c35ce5c93568c125 upstream.

mt7925_usb_sdio_tx_prepare_skb() pushes a TX descriptor and a USB
header onto every skb and assumes the headroom for them is already
there. That holds for locally generated traffic, where mac80211
reserves hw->extra_tx_headroom, but forwarded frames are sent through
ieee80211_8023_xmit(), which does not reserve it. Bridge a wired
interface to an mt7925u AP and the first forwarded frame that arrives
short panics the kernel:

 skbuff: skb_under_panic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1
 kernel BUG at net/core/skbuff.c:212!
 Call trace:
  skb_panic+0x58/0x60 (P)
  skb_push+0x58/0x60
  mt7925_usb_sdio_tx_prepare_skb+0xf8/0x1b8 [mt7925_common]
  mt76u_tx_queue_skb+0xa0/0x1f8 [mt76_usb]
  __mt76_tx_queue_skb+0x54/0xe8 [mt76]
  mt76_txq_schedule.part.0+0x204/0x478 [mt76]
  mt76_txq_schedule_all+0x50/0x80 [mt76]
  mt792x_tx_worker+0x68/0x100 [mt792x_lib]
  __mt76_worker_fn+0x84/0x150 [mt76]

Whether a given setup hits it depends on how much headroom the ingress
netdev leaves in its rx skbs. Reproduced on a Raspberry Pi 5 bridging
onboard ethernet to a Netgear A9000; originally reported on an MT7986
router running OpenWrt. Nick Morrow's testing on a Pi 4 (bcmgenet),
which leaves more headroom, helped narrow the trigger to the ingress
path.

The same bug was fixed on mt7921 by commit 98c4d0abf5c4 ("mt76:
mt7921: don't assume adequate headroom for SDIO headers"), but mt7925
was copied from mt7921 without the fix. Add the same guard here.

Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Cc: stable@vger.kernel.org
Link: https://github.com/morrownr/mt76/issues/52
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Link: https://patch.msgid.link/20260715023348.59506-1-lucid_duck@justthetip.ca
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vxlan: keep the last remote linked during FDB flush 2026-09-02T12:33:20+00:00 Kyle Zeng kylebot@openai.com 2026-08-10T14:41:14+00:00 4bbc76ee1b21d3bd045d6d819b2bacd30a6372ab commit d5d4a7b538b52db63927773a8905fcd9f78a42e2 upstream. A non-nexthop FDB entry is expected to have at least one remote while it remains reachable through the FDB hash table. A filtered bulk flush violates this invariant when every remote matches: It unlinks the last remote in vxlan_fdb_dst_destroy() and only afterwards tells vxlan_flush() to destroy the parent FDB entry. An RCU reader can find the parent during this interval. first_remote_rcu() then applies list_entry_rcu() to the empty list head, producing an invalid remote pointer that the receive learning path can read from and write to. When a matching remote is the sole remaining remote, leave it linked and ask the caller to destroy the entire FDB entry. vxlan_fdb_destroy() keeps the remote attached while sending the deletion notification and removing the parent from the lookup structures. Fixes: c499fccb71cb ("vxlan: vxlan_core: Support FDB flushing by destination VNI") Cc: stable@vger.kernel.org Signed-off-by: Kyle Zeng <kylebot@openai.com> Co-developed-by: David Lee <david.lee@trailofbits.com> Signed-off-by: David Lee <david.lee@trailofbits.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260810144115.821654-1-david.lee@trailofbits.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d5d4a7b538b52db63927773a8905fcd9f78a42e2 upstream.

A non-nexthop FDB entry is expected to have at least one remote while it
remains reachable through the FDB hash table. A filtered bulk flush
violates this invariant when every remote matches: It unlinks the last
remote in vxlan_fdb_dst_destroy() and only afterwards tells vxlan_flush()
to destroy the parent FDB entry.

An RCU reader can find the parent during this interval.
first_remote_rcu() then applies list_entry_rcu() to the empty list head,
producing an invalid remote pointer that the receive learning path can
read from and write to.

When a matching remote is the sole remaining remote, leave it linked and
ask the caller to destroy the entire FDB entry. vxlan_fdb_destroy() keeps
the remote attached while sending the deletion notification and removing
the parent from the lookup structures.

Fixes: c499fccb71cb ("vxlan: vxlan_core: Support FDB flushing by destination VNI")
Cc: stable@vger.kernel.org
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Co-developed-by: David Lee <david.lee@trailofbits.com>
Signed-off-by: David Lee <david.lee@trailofbits.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260810144115.821654-1-david.lee@trailofbits.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gtp: serialize PDP context updates 2026-09-02T12:33:18+00:00 Qing Ming a0yami@mailbox.org 2026-08-18T15:00:00+00:00 1e995498d29784a06a2b2899370a1926cfc8410d commit 498386b6d402737db1e2eeed4c385acbf0ef9e34 upstream. PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU. Running both paths concurrently can therefore make both paths delete the same PDP context. The issue was found through static analysis and reproduced on a KASAN-enabled kernel by a simple two-thread program racing GTP_CMD_DELPDP against RTM_DELLINK: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp] RBP: dead000000000122 The second deletion dereferenced the poisoned hlist pprev pointer. Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex. Keep the mutex held until the final use of a PDP context in the NEWPDP path, and keep the RCU read-side section around the complete PDP context use in the DELPDP path. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Cc: stable@vger.kernel.org Signed-off-by: Qing Ming <a0yami@mailbox.org> Link: https://patch.msgid.link/20260818150000.7670-1-a0yami@mailbox.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 498386b6d402737db1e2eeed4c385acbf0ef9e34 upstream.

PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP
network device is being unregistered. The latter is serialized by RTNL,
but the generic-netlink delete path only holds RCU.

Running both paths concurrently can therefore make both paths delete the
same PDP context. The issue was found through static analysis and
reproduced on a KASAN-enabled kernel by a simple two-thread program
racing GTP_CMD_DELPDP against RTM_DELLINK:

  Oops: general protection fault, probably for non-canonical address
  KASAN: maybe wild-memory-access in range
         [0xdead000000000120-0xdead000000000127]
  RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp]
  RBP: dead000000000122

The second deletion dereferenced the poisoned hlist pprev pointer.

Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a
shared mutex. Keep the mutex held until the final use of a PDP context in
the NEWPDP path, and keep the RCU read-side section around the complete
PDP context use in the DELPDP path.

Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Cc: stable@vger.kernel.org
Signed-off-by: Qing Ming <a0yami@mailbox.org>
Link: https://patch.msgid.link/20260818150000.7670-1-a0yami@mailbox.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/ionic: avoid OOB TX partner lookup for hwstamp RXQ 2026-08-27T12:35:25+00:00 Anand Khoje anand.a.khoje@oracle.com 2026-08-13T08:37:05+00:00 ea081b4435515ac7177eb598a3c0678d1b9e7911 commit d92255b405fb6f5acca408239ccd742e0a42c9cb upstream. The dedicated hardware timestamp RX queue is allocated with q->index equal to lif->ionic->nrxqs_per_lif. The normal txqcqs array only contains the regular queue pairs, so using that index to set rxq->partner can read one entry past txqcqs[] and then write through the derived pointer. Only link RX/TX partners for normal queue-pair indexes. Leave the hwstamp RX queue unpaired, and make the XDP_TX path abort cleanly if an RX queue has no TX partner. Fixes: 8eeed8373e1c ("ionic: Add XDP_TX support") Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com> Reviewed-by: Shannon Nelson <sln@onemain.com> Cc: stable@vger.kernel.org Signed-off-by: Anand Khoje <anand.a.khoje@oracle.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260813083705.454897-1-anand.a.khoje@oracle.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d92255b405fb6f5acca408239ccd742e0a42c9cb upstream.

The dedicated hardware timestamp RX queue is allocated with q->index
equal to lif->ionic->nrxqs_per_lif. The normal txqcqs array only
contains the regular queue pairs, so using that index to set rxq->partner
can read one entry past txqcqs[] and then write through the derived
pointer.
Only link RX/TX partners for normal queue-pair indexes. Leave the hwstamp
RX queue unpaired, and make the XDP_TX path abort cleanly if an RX queue
has no TX partner.

Fixes: 8eeed8373e1c ("ionic: Add XDP_TX support")
Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com>
Reviewed-by: Shannon Nelson <sln@onemain.com>
Cc: stable@vger.kernel.org
Signed-off-by: Anand Khoje <anand.a.khoje@oracle.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Brett Creeley <brett.creeley@amd.com>
Link: https://patch.msgid.link/20260813083705.454897-1-anand.a.khoje@oracle.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rndis_host: add overflow check in rndis_rx_fixup() 2026-08-27T12:35:21+00:00 Griffin Kroah-Hartman griffin@kroah.com 2026-07-09T12:24:01+00:00 2ded89ca77fae1da6886fe94831acfe4d6aa80b1 commit 965a251f23ff69cfb4486974d4532e9bb551c7fc upstream. Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer. Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Shaoxu Liu <shaoxul@foxmail.com> Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/2026070900-denim-brook-52d4@gregkh Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 965a251f23ff69cfb4486974d4532e9bb551c7fc upstream.

Add an overflow check to ensure that data_offset + data_len + 8 does not
wrap, which would enable an OOB read of the USB data buffer.

Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Shaoxu Liu <shaoxul@foxmail.com>
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/2026070900-denim-brook-52d4@gregkh
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
wifi: mt76: mt7921: refactor regd update to fix recursive mutex deadlock 2026-08-16T18:07:18+00:00 Charlie-cy Wu charlie-cy.wu@mediatek.corp-partner.google.com 2026-06-29T08:35:43+00:00 d6e7d57ed967def9c964a58328ffba409f7efb64 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 <Charlie-cy.Wu@mediatek.com> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
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 <Charlie-cy.Wu@mediatek.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Revert "wifi: mt76: Disable napi when removing device" 2026-08-13T16:00:55+00:00 Mikhail Gavrilov mikhail.v.gavrilov@gmail.com 2026-08-04T12:00:04+00:00 3aa1dcaa4f6f5ae08936491e08bd456f331f2d40 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: <TASK> __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 </TASK> 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 <spasswolf@web.de> 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 <mikhail.v.gavrilov@gmail.com> Acked-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Fixes: 13b7e6a96a00 ("wifi: mt76: Disable napi when removing device") Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
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:
   <TASK>
   __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
   </TASK>

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 <spasswolf@web.de>
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 <mikhail.v.gavrilov@gmail.com>
Acked-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Fixes: 13b7e6a96a00 ("wifi: mt76: Disable napi when removing device")
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'ovpn-net-20260809' of https://github.com/OpenVPN/ovpn-net-next 2026-08-13T01:09:18+00:00 Jakub Kicinski kuba@kernel.org 2026-08-13T01:09:18+00:00 2bb155e92167cd5ad6aae312e83291da2454f8b0 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 <horms@kernel.org> Link: https://patch.msgid.link/20260809212142.2249027-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
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 <horms@kernel.org>
Link: https://patch.msgid.link/20260809212142.2249027-1-antonio@openvpn.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG 2026-08-13T00:36:19+00:00 Siddharth Vadapalli s-vadapalli@ti.com 2026-08-07T11:17:37+00:00 36a05d2820077bb3955acb8111e1041d39148037 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 <s-vadapalli@ti.com> Reviewed-by: Chintan Vankar <c-vankar@ti.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260807111738.2055900-1-s-vadapalli@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
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 <s-vadapalli@ti.com>
Reviewed-by: Chintan Vankar <c-vankar@ti.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260807111738.2055900-1-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gve: fix NULL dereference due to missing ptp adjfine 2026-08-12T01:26:04+00:00 Jordan Rhee jordanrhee@google.com 2026-08-07T22:43:15+00:00 3992ced109c70b771efad9e51ae68e5c7a04dea3 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] <TASK> [ 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 <jordanrhee@google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260807224315.234152-3-hramamurthy@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
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]  <TASK>
[  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 <jordanrhee@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260807224315.234152-3-hramamurthy@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>