kernel/git/stable/linux-stable.git/drivers/net, branch linux-5.10.y

net: fec: only stop PTP if it was initialized

2026-09-14T11:19:18+00:00

[ Upstream commit dd890ae29299636fb037276fc1b5238698d08b03 ] fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized. Fixes: 32cba57ba74b ("net: fec: introduce fec_ptp_stop and use in probe fail path") Reviewed-by: Wei Fang Reviewed-by: Frank Li Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260826103428.32807-1-phucduc.bui@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: stmmac: selftests: Account for the UC filter list for filtering tests

2026-09-14T11:19:18+00:00

[ Upstream commit cd8c3b2752c684141eab2282e294cae2971a9759 ] On dwmac, one of the Unicast filter entries is used to store the local HW addr. This means that we have to use promisc mode for any kind of unicast filtering if we only have one slot in our unicast filter. The number of slots available depends on how the IP is integrated, and we can't autodiscover how many of these slots we have available, so the DT property snps,perfect-filter-entries can be used to specify how many are available. Most IP variants default to 1 if this isn't specified, which is the case for the amlogic variants (in this case, S905X3). The stmmac selftests for UC filtering look if we have enough slots in the filter to store the dev->uc list, but doesn't account for the device's own MAC address. The dev->uc list's size we get with netdev_uc_count() also doesn't account for the HW addr. As the selftest only requires one available slot, in the case of single-slot platforms, that means we erroneously consider we have enough room for the test, when we actually don't, and the filtering test fails. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-6-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering

2026-09-14T11:19:18+00:00

[ Upstream commit 2739d6f9a2b8729b0d85cbe0dc93e1d68670b6f2 ] The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 0efedbf11f07 ("net: stmmac: xgmac: Fix XGMAC selftests") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-5-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: stmmac: dwmac4: Account for the primary MAC address for UC filtering

2026-09-14T11:19:18+00:00

[ Upstream commit 82187f42c014d22520b9c3c4e2cfb519223fb29b ] The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 477286b53f55 ("stmmac: add GMAC4 core support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-4-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering

2026-09-14T11:19:18+00:00

[ Upstream commit 9698b6da3714fd2ef47846cb63098d2b2d252e25 ] The same filter slots are used to store the main MAC address as well as the address for the unicast filter. Let's account for that when deciding whether or not to use promisc when programming the UC list in hardware. Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-3-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: stmmac: selftests: Check multiple MMC counters

2026-09-14T11:19:18+00:00

[ Upstream commit d29b399150b07796dfa81d8778d4804c08c2a41d ] The MMC counters report MAC statistics. Multiple counters can be enabled when the IP is integrated, however there's no way to know exactly which ones. Un-implemented counters seem to report 0. It was found that on StarFive JH7110 and Amlogic SM1, the counter that's used by the selftest (mmc_tx_framecount_g) isn't implemented, triggering an MMC selftest failure. Both the above SoCs seem to implement mmc_rx_framecount_gb, let's use this counter as well for MMC counter validation. Note that this doesn't guarantee that we won't encounter the same issue again if another IP implements yet another set of counters that don't include that new one. If the game of whack-a-mole with implemented counters becomes too hard to maintain, we may simply consider removing the MMC selftest entirely. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Maxime Chevallier Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260826140500.616466-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: ethernet: sun4i-emac: Fix IRQ error handling

2026-09-14T11:19:18+00:00

[ Upstream commit 991c2be78257cba5bf53cf935fe70f8836964288 ] irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails. The current code checks for -ENXIO and therefore does not detect the failure. Check for a zero return value and convert it to -ENXIO. Fixes: 492205050d77 ("net: Add EMAC ethernet driver found on Allwinner A10 SoC's") Signed-off-by: bui duc phuc Reviewed-by: Andre Przywara Link: https://patch.msgid.link/20260824100901.31675-1-phucduc.bui@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: qualcomm: rmnet: restore skb->dev on deaggregated frames

2026-09-14T11:19:17+00:00

[ Upstream commit a66734a1c5e36525ea07e9f4547fddc51e916de3 ] rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt Fixes: 378e25357ac7 ("net: qualcomm: rmnet: Remove unnecessary device assignment") Reported-by: co+4638111fe2a12980@bugs.sh Closes: https://lore.kernel.org/netdev/ijg79FFMfIvKJbivdJEKvTO90Q9dTvyBkJck@bugs.sh/T/#u Signed-off-by: Xiang Mei Reviewed-by: Subash Abhinov Kasiviswanathan Link: https://patch.msgid.link/20260820195240.1631458-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free

2026-09-14T11:19:17+00:00

[ Upstream commit d989e22ae9802c52c56ad4284d0caf26696cf6ae ] gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets(). Fixes: 459aa660eb1d8ce6 ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) Reported-by: Cen Zhang (Microsoft) Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20260820020735.59474-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

forcedeth: stop the tx_timeout register dump past the requested window

2026-09-14T11:19:16+00:00

[ Upstream commit cfa9178ce2e5b4f2e2a9e8b577a6cff841665aa0 ] nv_tx_timeout() dumps the register window in rows of eight dwords: for (i = 0; i <= np->register_size; i += 32) { netdev_info(dev, "%3x: %08x ... %08x\n", i, readl(base + i + 0), ..., readl(base + i + 28)); The loop bound only checks the row's starting offset, so the final row reads a full 32 bytes from a position that is below the end of the window but too close to it. base is mapped with exactly that length: np->base = ioremap(addr, np->register_size); so the tail of that row is read from beyond the length the driver asked for. Per variant, the last iteration reads past register_size by: NV_PCI_REGSZ_VER1 (0x270): row 0x260 reads to 0x27f, 16 bytes over NV_PCI_REGSZ_VER2 (0x2d4): row 0x2c0 reads to 0x2df, 12 bytes over NV_PCI_REGSZ_VER3 (0x604): row 0x600 reads to 0x61f, 28 bytes over This happens on every supported device, not just one of them. Note that it is not a consequence of the sizes being odd: with i <= register_size the offending row is reached whatever the size, and a size that were a multiple of 32 would overrun by a full row rather than by a remainder. To be precise about the severity: the reads stay inside the BAR. Memory BAR sizes are powers of two, the driver only accepts a region with pci_resource_len() >= register_size (forcedeth.c:5757-5762), and the next power of two at or above each register_size already covers the offending row: 0x400 for 0x270 and 0x2d4, 0x800 for 0x604. ioremap() also rounds the mapped length up to page granularity, so the reads land inside the mapping the CPU has as well. What they leave is the window the driver asked for, not the BAR and not the mapping. That is still a driver reading registers it did not ask for, and it is trivial to avoid, but nobody should expect a fault from it. Changing <= to < is not enough: register_size is a length and every size above is larger than its last row start, so i still reaches the offending row. Check that the whole row fits instead. The trade-off is that a partial trailing row is no longer dumped: 16 bytes for VER1, 20 for VER2, 4 for VER3. That seemed preferable to reading outside the requested window, and to open-coding a second, narrower dump for the remainder in what is a debug-only path. Extending the dump to cover the tail can be done on top if anyone misses those registers. Only reachable with the debug_tx_timeout module parameter, which defaults to false. It has not been observed at runtime: forcing a genuine TX timeout on the reference machine is not something I can do safely, so this rests on the arithmetic above and on a build test, not on a reproduction. UBSAN does not catch it either, since these are MMIO reads rather than an array access. It was found by reading the function while fixing the saved_config_space off-by-one in nv_suspend() and nv_resume(). The dump was introduced with a fixed 0x400 bound while ioremap() mapped only NV_PCI_REGSZ (0x270), so it read about 0x190 bytes too far from the start. Commit 86a0f04387bf ("[PATCH] forcedeth: fix initialization") later replaced 0x400 with np->register_size, which shrank the overrun to the remainder but did not remove it. Fixes: c2dba06dae7d ("[PATCH] forcedeth: rewritten tx irq handling") Signed-off-by: Marek Czernohous Reviewed-by: Simon Horman Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/178682367886.3748309.6978554332066826294@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin