summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-03-05net: bridge: fix nd_tbl NULL dereference when IPv6 is disabledFernando Fernandez Mancera
When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. Then, if neigh_suppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, br_do_suppress_nd() will dereference ipv6_stub->nd_tbl which is NULL, passing it to neigh_lookup(). This causes a kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neigh_lookup+0x16/0xe0 [...] Call Trace: <IRQ> ? neigh_lookup+0x16/0xe0 br_do_suppress_nd+0x160/0x290 [bridge] br_handle_frame_finish+0x500/0x620 [bridge] br_handle_frame+0x353/0x440 [bridge] __netif_receive_skb_core.constprop.0+0x298/0x1110 __netif_receive_skb_one_core+0x3d/0xa0 process_backlog+0xa0/0x140 __napi_poll+0x2c/0x170 net_rx_action+0x2c4/0x3a0 handle_softirqs+0xd0/0x270 do_softirq+0x3f/0x60 Fix this by replacing IS_ENABLED(IPV6) call with ipv6_mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled. Fixes: ed842faeb2bd ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports") Reported-by: Guruprasad C P <gurucp2005@gmail.com> Closes: https://lore.kernel.org/netdev/CAHXs0ORzd62QOG-Fttqa2Cx_A_VFp=utE2H2VTX5nqfgs7LDxQ@mail.gmail.com/ Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260304120357.9778-1-fmancera@suse.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05ata: libata-core: Add BRIDGE_OK quirk for QEMU drivesPedro Falcato
Currently, whenever you boot with a QEMU drive over an AHCI interface, you get: [ 1.632121] ata1.00: applying bridge limits This happens due to the kernel not believing the given drive is SATA, since word 93 of IDENTIFY (ATA_ID_HW_CONFIG) is non-zero. The result is a pretty severe limit in max_hw_sectors_kb, which limits our IO sizes. QEMU has set word 93 erroneously for SATA drives but does not, in any way, emulate any of these real hardware details. There is no PATA drive and no SATA cable. As such, add a BRIDGE_OK quirk for QEMU HARDDISK. Special care is taken to limit this quirk to "2.5+", to allow for fixed future versions. This results in the max_hw_sectors being limited solely by the controller interface's limits. Which, for AHCI controllers, takes it from 128KB to 32767KB. Cc: stable@vger.kernel.org Signed-off-by: Pedro Falcato <pfalcato@suse.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-03-05KVM: arm64: nv: Inject a SEA if failed to read the descriptorZenghui Yu (Huawei)
Failure to read the descriptor (because it is outside of a memslot) should result in a SEA being injected in the guest. Suggested-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/86ms1m9lp3.wl-maz@kernel.org Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Link: https://patch.msgid.link/20260225173515.20490-4-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-05KVM: arm64: nv: Report addrsz fault at level 0 with a bad VTTBR.BADDRZenghui Yu (Huawei)
As per R_BFHQH, " When an Address size fault is generated, the reported fault code indicates one of the following: If the fault was generated due to the TTBR_ELx used in the translation having nonzero address bits above the OA size, then a fault at level 0. " Fix the reported Address size fault level as being 0 if the base address is wrongly programmed by L1. Fixes: 61e30b9eef7f ("KVM: arm64: nv: Implement nested Stage-2 page table walk logic") Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Link: https://patch.msgid.link/20260225173515.20490-3-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-05KVM: arm64: nv: Check S2 limits based on implemented PA sizeZenghui Yu (Huawei)
check_base_s2_limits() checks the validity of SL0 and inputsize against ia_size (inputsize again!) but the pseudocode from DDI0487 G.a AArch64.TranslationTableWalk() says that we should check against the implemented PA size. We would otherwise fail to walk S2 with a valid configuration. E.g., granule size = 4KB, inputsize = 40 bits, initial lookup level = 0 (no concatenation) on a system with 48 bits PA range supported is allowed by architecture. Fix it by obtaining PA size by kvm_get_pa_bits(). Note that kvm_get_pa_bits() returns the fixed limit now and should eventually reflect the per VM PARange (one day!). Given that the configured PARange should not be greater that kvm_ipa_limit, it at least fixes the problem described above. While at it, inject a level 0 translation fault to guest if check_base_s2_limits() fails, as per the pseudocode. Fixes: 61e30b9eef7f ("KVM: arm64: nv: Implement nested Stage-2 page table walk logic") Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Link: https://patch.msgid.link/20260225173515.20490-2-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-05Merge branch 'maintainers-annual-cleanup-of-inactive-maintainers'Jakub Kicinski
Jakub Kicinski says: ==================== MAINTAINERS: annual cleanup of inactive maintainers Annual cleanup of inactive maintainers under networking. The goal is to make sure MAINTAINERS reflect reality for code which is relatively actively changed (at least 70 commits in the last 2 years or at least 120 commits in the last 5 years). Those who either: - were the initial author / "upstreamer" of the driver; or - authored at least 1/3rd of the exiting code base (per git blame); or - authored at least 25% of commits before becoming inactive are moved to CREDITS. The discovery of inactive maintainers was done using gitdm tools, with a bunch of ad-hoc scripts on top to do the rest. I tried to double check the results but this is mostly a scripted cleanup so please report inaccuracies if any. ==================== Link: https://patch.msgid.link/20260303215339.2333548-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: remove Thomas Falcon from IBM ibmvnicJakub Kicinski
We have not seen emails or tags from Thomas's IBM address (tlfalcon@linux.ibm.com) in over 5 years. Looks like Thomas is active in perf tooling at Intel (thomas.falcon@intel.com). Subsystem IBM Power SRIOV Virtual NIC Device Driver Changes 49 / 134 (36%) Last activity: 2025-08-26 Haren Myneni <haren@linux.ibm.com>: Tags 3c14917953a5 2025-08-26 00:00:00 2 Rick Lindsley <ricklind@linux.ibm.com>: Nick Child <nnac123@linux.ibm.com>: Author d93a6caab5d7 2025-03-25 00:00:00 14 Tags d93a6caab5d7 2025-03-25 00:00:00 16 Thomas Falcon <tlfalcon@linux.ibm.com>: Top reviewers: [22]: drt@linux.ibm.com [13]: horms@kernel.org [9]: ricklind@linux.vnet.ibm.com [3]: davemarq@linux.ibm.com INACTIVE MAINTAINER Thomas Falcon <tlfalcon@linux.ibm.com> Move Thomas to CREDITS as the initial author of ibmvnic. Acked-by: Thomas Falcon <thomas.falcon@intel.com> Link: https://patch.msgid.link/20260303215339.2333548-12-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: remove Claudiu Manoil and Alexandre Belloni from Ocelot switchJakub Kicinski
We have not seen tags from Claudiu for the Ocelot switch driver in over 5 years. He is active upstream in other NXP subsystems (ENETC, gianfar), with 46 emails on lore since 2024. We have not seen tags from Alexandre for the Ocelot switch driver in over 5 years. He is very active upstream in other subsystems (RTC, I3C, Atmel/Microchip SoC), with over 1,200 emails on lore since 2024. Vladimir Oltean is active. Subsystem OCELOT ETHERNET SWITCH DRIVER Changes 180 / 494 (36%) Last activity: 2026-02-12 Vladimir Oltean <vladimir.oltean@nxp.com>: Author c22ba07c827f 2026-02-10 00:00:00 33 Tags 026f6513c588 2026-02-12 00:00:00 39 Claudiu Manoil <claudiu.manoil@nxp.com>: Alexandre Belloni <alexandre.belloni@bootlin.com>: Top reviewers: [49]: f.fainelli@gmail.com [19]: horms@kernel.org [10]: richardcochran@gmail.com [9]: jacob.e.keller@intel.com [8]: colin.foster@in-advantage.com INACTIVE MAINTAINER Claudiu Manoil <claudiu.manoil@nxp.com> Acked-by: Claudiu Manoil <claudiu.manoil@nxp.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://patch.msgid.link/20260303215339.2333548-11-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: replace Taras Chornyi with Elad Nachman for Marvell PresteraJakub Kicinski
We have not seen emails or tags from Taras in over 5 years, and there is no recent mailing list activity. Elad Nachman has been providing reviews in the last couple of years and is the top reviewer for this subsystem. Subsystem MARVELL PRESTERA ETHERNET SWITCH DRIVER Changes 39 / 157 (24%) (No activity) Top reviewers: [8]: enachman@marvell.com [6]: horms@kernel.org [4]: idosch@nvidia.com [3]: andrew@lunn.ch [3]: jacob.e.keller@intel.com [3]: jiri@nvidia.com INACTIVE MAINTAINER Taras Chornyi <taras.chornyi@plvision.eu> Link: https://patch.msgid.link/20260303215339.2333548-10-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: remove Jonathan Lemon from OpenCompute PTPJakub Kicinski
We have not seen emails or tags from Jonathan in over 5 years, and there is no recent mailing list activity. Vadim Fedorenko is active. Subsystem OPENCOMPUTE PTP CLOCK DRIVER Changes 49 / 130 (37%) Last activity: 2025-11-25 Jonathan Lemon <jonathan.lemon@gmail.com>: Vadim Fedorenko <vadim.fedorenko@linux.dev>: Author d3ca2ef0c915 2025-09-19 00:00:00 5 Tags 648282e2d1e5 2025-11-25 00:00:00 20 Top reviewers: [7]: horms@kernel.org [4]: jiri@nvidia.com [3]: richardcochran@gmail.com [2]: aleksandr.loktionov@intel.com INACTIVE MAINTAINER Jonathan Lemon <jonathan.lemon@gmail.com> Add Jonathan to CREDITS as the initial author of ptp_ocp. Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260303215339.2333548-9-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: replace Clark Wang with Frank Li for Freescale FECJakub Kicinski
We have not seen tags from Clark for FEC in over 5 years. He has some limited recent activity on the mailing list in other NXP subsystems (stmmac, phy). Wei Fang and Shenwei Wang are active, with decent review coverage (61%). Frank Li has been reviewing code actively more recenty, let's make it official. Subsystem FREESCALE IMX / MXC FEC DRIVER Changes 57 / 92 (61%) Last activity: 2026-02-10 Wei Fang <wei.fang@nxp.com>: Author 25eb3058eb70 2026-02-10 00:00:00 33 Tags 25eb3058eb70 2026-02-10 00:00:00 61 Shenwei Wang <shenwei.wang@nxp.com>: Author d466c16026e9 2025-09-14 00:00:00 6 Tags d466c16026e9 2025-09-14 00:00:00 6 Clark Wang <xiaoning.wang@nxp.com>: Top reviewers: [23]: Frank.Li@nxp.com [17]: andrew@lunn.ch [4]: csokas.bence@prolan.hu [3]: horms@kernel.org [2]: maxime.chevallier@bootlin.com INACTIVE MAINTAINER Clark Wang <xiaoning.wang@nxp.com> Reviewed-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260303215339.2333548-8-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: remove DENG Qingfang from MediaTek switchJakub Kicinski
We have not seen tags from DENG Qingfang for the MediaTek switch driver in over 5 years. He is active upstream with PPP/PPPoE patches in net-next. Chester and Daniel are active. Subsystem MEDIATEK SWITCH DRIVER Changes 26 / 70 (37%) Last activity: 2025-12-01 Chester A. Unal <chester.a.unal@arinc9.com>: Tags 585943b7ad30 2025-12-01 00:00:00 7 Daniel Golle <daniel@makrotopia.org>: Author 497041d76301 2025-04-23 00:00:00 2 Tags 3b87e60d2131 2025-12-01 00:00:00 14 DENG Qingfang <dqfext@gmail.com>: Sean Wang <sean.wang@mediatek.com>: Top reviewers: [4]: andrew@lunn.ch [4]: florian.fainelli@broadcom.com [4]: arinc.unal@arinc9.com [2]: olteanv@gmail.com INACTIVE MAINTAINER DENG Qingfang <dqfext@gmail.com> Acked-by: Chester A. Unal <chester.a.unal@arinc9.com> Link: https://patch.msgid.link/20260303215339.2333548-7-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: remove Sean Wang from MediaTek Ethernet and switchJakub Kicinski
We have not seen tags from Sean in over 5 years, with only one mailing list post since 2024. Felix and Lorenzo are active for the Ethernet driver, and Chester, Daniel and DENG Qingfang are active for the switch driver. Subsystem MEDIATEK ETHERNET DRIVER Changes 55 / 113 (48%) Last activity: 2025-10-12 Felix Fietkau <nbd@nbd.name>: Author d4736737110f 2025-09-02 00:00:00 3 Tags d4736737110f 2025-09-02 00:00:00 4 Sean Wang <sean.wang@mediatek.com>: Lorenzo Bianconi <lorenzo@kernel.org>: Author 96326447d466 2025-08-13 00:00:00 35 Tags 3abc0e55ea1f 2025-10-12 00:00:00 40 Top reviewers: [26]: horms@kernel.org [5]: andrew@lunn.ch [4]: jacob.e.keller@intel.com [3]: shannon.nelson@amd.com [3]: michal.swiatkowski@linux.intel.com INACTIVE MAINTAINER Sean Wang <sean.wang@mediatek.com> Subsystem MEDIATEK SWITCH DRIVER Changes 26 / 70 (37%) Last activity: 2025-12-01 Chester A. Unal <chester.a.unal@arinc9.com>: Tags 585943b7ad30 2025-12-01 00:00:00 7 Daniel Golle <daniel@makrotopia.org>: Author 497041d76301 2025-04-23 00:00:00 2 Tags 3b87e60d2131 2025-12-01 00:00:00 14 DENG Qingfang <dqfext@gmail.com>: Sean Wang <sean.wang@mediatek.com>: Top reviewers: [4]: andrew@lunn.ch [4]: florian.fainelli@broadcom.com [4]: arinc.unal@arinc9.com [2]: olteanv@gmail.com INACTIVE MAINTAINER Sean Wang <sean.wang@mediatek.com> Acked-by: Chester A. Unal <chester.a.unal@arinc9.com> Link: https://patch.msgid.link/20260303215339.2333548-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: remove Jerin Jacob from Marvell OcteonTX2Jakub Kicinski
We have not seen tags from Jerin for OcteonTX2 in over 5 years. Recent lore activity is in DPDK (non-kernel), not Linux. Sunil, Linu, Geetha, hariprasad, and Subbaraya are active, though the review coverage isn't great (38%). Subsystem MARVELL OCTEONTX2 RVU ADMIN FUNCTION DRIVER Changes 53 / 138 (38%) Last activity: 2026-02-18 Sunil Goutham <sgoutham@marvell.com>: Author fc1b2901e0fe 2024-03-08 00:00:00 1 Tags 70f8986ecef1 2025-06-16 00:00:00 9 Linu Cherian <lcherian@marvell.com>: Author a861e5809f3e 2025-10-30 00:00:00 7 Tags a861e5809f3e 2025-10-30 00:00:00 7 Geetha sowjanya <gakula@marvell.com>: Author 70e9a5760abf 2026-01-29 00:00:00 16 Tags 70e9a5760abf 2026-01-29 00:00:00 20 Jerin Jacob <jerinj@marvell.com>: hariprasad <hkelam@marvell.com>: Author 45be47bf5d7d 2026-02-18 00:00:00 22 Tags 45be47bf5d7d 2026-02-18 00:00:00 25 Subbaraya Sundeep <sbhatta@marvell.com>: Author 47a1208776d7 2025-10-30 00:00:00 20 Tags 47a1208776d7 2025-10-30 00:00:00 30 Top reviewers: [36]: horms@kernel.org [4]: jacob.e.keller@intel.com [4]: kalesh-anakkur.purayil@broadcom.com [3]: vadim.fedorenko@linux.dev [2]: shaojijie@huawei.com [2]: jiri@nvidia.com INACTIVE MAINTAINER Jerin Jacob <jerinj@marvell.com> Link: https://patch.msgid.link/20260303215339.2333548-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: remove Manish Chopra from QLogic QL4xxx (now orphan)Jakub Kicinski
We have not seen tags from Manish for the QL4xxx driver in over 5 years, and there is no mailing list activity since Oct 2023. There has been no maintainer activity in this subsystem at all. Since there is no other maintainer for this driver it becomes an Orphan. Subsystem QLOGIC QL4xxx ETHERNET DRIVER Changes 40 / 74 (54%) (No activity) Top reviewers: [30]: horms@kernel.org [2]: jiri@nvidia.com [2]: shannon.nelson@amd.com [1]: saeedm@nvidia.com [1]: aleksandr.loktionov@intel.com [1]: kory.maincent@bootlin.com INACTIVE MAINTAINER Manish Chopra <manishc@marvell.com> Link: https://patch.msgid.link/20260303215339.2333548-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05MAINTAINERS: remove Johan Hedberg from Bluetooth subsystemJakub Kicinski
We have not seen emails or tags from Johan in over 5 years, and there is no recent mailing list activity. Marcel Holtmann hasn't provided any tags in the Bluetooth subsystem in over 5 years, but he is active on the Bluetooth mailing list, providing informal review. Luiz Augusto von Dentz is very active, handling essentially all commits and reviews (12% coverage, but Luiz is the sole active committer). Subsystem BLUETOOTH SUBSYSTEM Changes 50 / 411 (12%) Last activity: 2026-02-23 Marcel Holtmann <marcel@holtmann.org>: Johan Hedberg <johan.hedberg@gmail.com>: Luiz Augusto von Dentz <luiz.dentz@gmail.com>: Author 138d7eca445e 2026-02-23 00:00:00 164 Committer 138d7eca445e 2026-02-23 00:00:00 361 Tags 138d7eca445e 2026-02-23 00:00:00 362 Top reviewers: [15]: pmenzel@molgen.mpg.de [8]: keescook@chromium.org [5]: willemb@google.com [4]: horms@kernel.org [3]: kuniyu@amazon.com [3]: luiz.von.dentz@intel.com INACTIVE MAINTAINER Johan Hedberg <johan.hedberg@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Link: https://patch.msgid.link/20260303215339.2333548-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05selftests: net: tun: don't abort XFAIL casesSun Jian
The tun UDP tunnel GSO fixture contains XFAIL-marked variants intended to exercise failure paths (e.g. EMSGSIZE / "Message too long"). Using ASSERT_EQ() in these tests aborts the subtest, which prevents the harness from classifying them as XFAIL and can make the overall net: tun test fail. Switch the relevant ASSERT_EQ() checks to EXPECT_EQ() so the subtests continue running and the failures are correctly reported and accounted as XFAIL where applicable. Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com> Link: https://patch.msgid.link/20260225111451.347923-2-sun.jian.kdev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05selftests/harness: order TEST_F and XFAIL_ADD constructorsSun Jian
TEST_F() allocates and registers its struct __test_metadata via mmap() inside its constructor, and only then assigns the _##fixture_##test##_object pointer. XFAIL_ADD() runs in a constructor too and reads _##fixture_##test##_object to initialize xfail->test. If XFAIL_ADD runs first, xfail->test can be NULL and the expected failure will be reported as FAIL. Use constructor priorities to ensure TEST_F registration runs before XFAIL_ADD, without adding extra state or runtime lookups. Fixes: 2709473c9386 ("selftests: kselftest_harness: support using xfail") Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com> Link: https://patch.msgid.link/20260225111451.347923-1-sun.jian.kdev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05Merge tag 'nf-26-03-05' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Florian Westphal says: ==================== netfilter: updates for net 1) Inseo An reported a bug with the set element handling in nf_tables: When set cannot accept more elements, we unlink and immediately free an element that was inserted into a public data structure, freeing it without waiting for RCU grace period. Fix this by doing the increment earlier and by deferring possible unlink-and-free to the existing abort path, which performs the needed synchronize_rcu before free. From Pablo Neira Ayuso. This is an ancient bug, dating back to kernel 4.10. 2) syzbot reported WARN_ON() splat in nf_tables that occurs on memory allocation failure. Fix this by a new iterator annotation: The affected walker does not need to clone the data structure and can just use the live version if no clone exists yet. Also from Pablo. This bug existed since 6.10 days. 3) Ancient forever bug in nft_pipapo data structure: The garbage collection logic to remove expired elements is broken. We must unlink from data structure and can only hand the freeing to call_rcu after the clone/live pointers of the data structures have been swapped. Else, readers can observe the free'd element. Reported by Yiming Qian. * tag 'nf-26-03-05' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase netfilter: nf_tables: clone set on flush only netfilter: nf_tables: unconditionally bump set->nelems before insertion ==================== Link: https://patch.msgid.link/20260305122635.23525-1-fw@strlen.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-05KVM: arm64: pkvm: Fallback to level-3 mapping on host stage-2 faultMarc Zyngier
If, for any odd reason, we cannot converge to mapping size that is completely contained in a memblock region, we fail to install a S2 mapping and go back to the faulting instruction. Rince, repeat. This happens when faulting in regions that are smaller than a page or that do not have PAGE_SIZE-aligned boundaries (as witnessed on an O6 board that refuses to boot in protected mode). In this situation, fallback to using a PAGE_SIZE mapping anyway -- it isn't like we can go any lower. Fixes: e728e705802fe ("KVM: arm64: Adjust range correctly during host stage-2 faults") Link: https://lore.kernel.org/r/86wlzr77cn.wl-maz@kernel.org Cc: stable@vger.kernel.org Cc: Quentin Perret <qperret@google.com> Reviewed-by: Quentin Perret <qperret@google.com> Link: https://patch.msgid.link/20260305132751.2928138-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-05KVM: arm64: Eagerly init vgic dist/redist on vgic creationMarc Zyngier
If vgic_allocate_private_irqs_locked() fails for any odd reason, we exit kvm_vgic_create() early, leaving dist->rd_regions uninitialised. kvm_vgic_dist_destroy() then comes along and walks into the weeds trying to free the RDs. Got to love this stuff. Solve it by moving all the static initialisation early, and make sure that if we fail halfway, we're in a reasonable shape to perform the rest of the teardown. While at it, reset the vgic model on failure, just in case... Reported-by: syzbot+f6a46b038fc243ac0175@syzkaller.appspotmail.com Tested-by: syzbot+f6a46b038fc243ac0175@syzkaller.appspotmail.com Fixes: b3aa9283c0c50 ("KVM: arm64: vgic: Hoist SGI/PPI alloc from vgic_init() to kvm_create_vgic()") Link: https://lore.kernel.org/r/69a2d58c.050a0220.3a55be.003b.GAE@google.com Link: https://patch.msgid.link/20260228164559.936268-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org
2026-03-05ftrace: Add MAINTAINERS entries for all ftrace headersJerome Marchand
There is currently no entry for ftrace_irq.h and ftrace_regs.h. Add a generic entry for all *ftrace* headers to include them and prevent overlooking future ftrace headers. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Link: https://patch.msgid.link/20260305093117.853700-1-jmarchan@redhat.com Signed-off-by: Jerome Marchand <jmarchan@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-03-05net: ethernet: mtk_eth_soc: Reset prog ptr to old_prog in case of error in ↵Lorenzo Bianconi
mtk_xdp_setup() Reset eBPF program pointer to old_prog and do not decrease its ref-count if mtk_open routine in mtk_xdp_setup() fails. Fixes: 7c26c20da5d42 ("net: ethernet: mtk_eth_soc: add basic XDP support") Suggested-by: Paolo Valerio <pvalerio@redhat.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260303-mtk-xdp-prog-ptr-fix-v2-1-97b6dbbe240f@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05Revert "drm/syncobj: Fix handle <-> fd ioctls with dirty stack"Maarten Lankhorst
This reverts commit 2e3649e237237258a08d75afef96648dd2b379f7. The problem occurs when userspace is compiled against new headers with new members, but don't correctly initialise those new members. This is not a kernel problem, and should be fixed in userspace by correctly zero'ing all members. Cc: Rob Clark <robdclark@chromium.org> Cc: Julian Orth <ju.orth@gmail.com> Cc: Christian König <christian.koenig@amd.com> Cc: Michel Dänzer <michel.daenzer@mailbox.org> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Julian Orth <ju.orth@gmail.com> Link: https://patch.msgid.link/20260305113734.1309238-1-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-03-05ALSA: us122l: drop redundant interface referencesJohan Hovold
Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Similarly, USB core holds a reference to all interfaces in the active configuration so there is no need for a driver to take a reference to a sibling interface only to release it at disconnect either. Drop the redundant references to reduce cargo culting, make it easier to spot drivers where extra references are needed, and reduce the risk of memory leaks when drivers fail to release them. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260305111810.18688-1-johan@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-03-05netfilter: nft_set_pipapo: split gc into unlink and reclaim phaseFlorian Westphal
Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a ("netfilter: nft_set_rbtree: don't gc elements on insert"). Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Reported-by: Yiming Qian <yimingqian591@gmail.com> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-03-05netfilter: nf_tables: clone set on flush onlyPablo Neira Ayuso
Syzbot with fault injection triggered a failing memory allocation with GFP_KERNEL which results in a WARN splat: iter.err WARNING: net/netfilter/nf_tables_api.c:845 at nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845, CPU#0: syz.0.17/5992 Modules linked in: CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845 Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43 +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9 RSP: 0018:ffffc900045af780 EFLAGS: 00010293 RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40 RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000 RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0 R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920 FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0 Call Trace: <TASK> __nft_release_table+0xceb/0x11f0 net/netfilter/nf_tables_api.c:12115 nft_rcv_nl_event+0xc25/0xdb0 net/netfilter/nf_tables_api.c:12187 notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85 blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380 netlink_release+0x123b/0x1ad0 net/netlink/af_netlink.c:761 __sock_release net/socket.c:662 [inline] sock_close+0xc3/0x240 net/socket.c:1455 Restrict set clone to the flush set command in the preparation phase. Add NFT_ITER_UPDATE_CLONE and use it for this purpose, update the rbtree and pipapo backends to only clone the set when this iteration type is used. As for the existing NFT_ITER_UPDATE type, update the pipapo backend to use the existing set clone if available, otherwise use the existing set representation. After this update, there is no need to clone a set that is being deleted, this includes bound anonymous set. An alternative approach to NFT_ITER_UPDATE_CLONE is to add a .clone interface and call it from the flush set path. Reported-by: syzbot+4924a0edc148e8b4b342@syzkaller.appspotmail.com Fixes: 3f1d886cc7c3 ("netfilter: nft_set_pipapo: move cloning of match info to insert/removal path") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-03-05netfilter: nf_tables: unconditionally bump set->nelems before insertionPablo Neira Ayuso
In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches. Fixes: 35d0ac9070ef ("netfilter: nf_tables: fix set->nelems counting with no NLM_F_EXCL") Reported-by: Inseo An <y0un9sa@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-03-05net: Provide a PREEMPT_RT specific check for netdev_queue::_xmit_lockSebastian Andrzej Siewior
After acquiring netdev_queue::_xmit_lock the number of the CPU owning the lock is recorded in netdev_queue::xmit_lock_owner. This works as long as the BH context is not preemptible. On PREEMPT_RT the softirq context is preemptible and without the softirq-lock it is possible to have multiple user in __dev_queue_xmit() submitting a skb on the same CPU. This is fine in general but this means also that the current CPU is recorded as netdev_queue::xmit_lock_owner. This in turn leads to the recursion alert and the skb is dropped. Instead checking the for CPU number, that owns the lock, PREEMPT_RT can check if the lockowner matches the current task. Add netif_tx_owned() which returns true if the current context owns the lock by comparing the provided CPU number with the recorded number. This resembles the current check by negating the condition (the current check returns true if the lock is not owned). On PREEMPT_RT use rt_mutex_owner() to return the lock owner and compare the current task against it. Use the new helper in __dev_queue_xmit() and netif_local_xmit_active() which provides a similar check. Update comments regarding pairing READ_ONCE(). Reported-by: Bert Karwatzki <spasswolf@web.de> Closes: https://lore.kernel.org/all/20260216134333.412332-1-spasswolf@web.de Fixes: 3253cb49cbad4 ("softirq: Allow to drop the softirq-BKL lock on PREEMPT_RT") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reported-by: Bert Karwatzki <spasswolf@web.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://patch.msgid.link/20260302162631.uGUyIqDT@linutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-05block: use trylock to avoid lockdep circular dependency in sysfsMing Lei
Use trylock instead of blocking lock acquisition for update_nr_hwq_lock in queue_requests_store() and elv_iosched_store() to avoid circular lock dependency with kernfs active reference during concurrent disk deletion: update_nr_hwq_lock -> kn->active (via del_gendisk -> kobject_del) kn->active -> update_nr_hwq_lock (via sysfs write path) Return -EBUSY when the lock is not immediately available. Reported-and-tested-by: Yi Zhang <yi.zhang@redhat.com> Closes: https://lore.kernel.org/linux-block/CAHj4cs-em-4acsHabMdT=jJhXkCzjnprD-aQH1OgrZo4nTnmMw@mail.gmail.com/ Fixes: 626ff4f8ebcb ("blk-mq: convert to serialize updating nr_requests with update_nr_hwq_lock") Signed-off-by: Ming Lei <ming.lei@redhat.com> Tested-by: Yi Zhang <yi.zhang@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-03-05RDMA/bng_re: Fix silent failure in HWRM version queryKamal Heib
If the firmware version query fails, the driver currently ignores the error and continues initializing. This leaves the device in a bad state. Fix this by making bng_re_query_hwrm_version() return the error code and update the driver to check for this error and stop the setup process safely if it happens. Fixes: 745065770c2d ("RDMA/bng_re: Register and get the resources from bnge driver") Signed-off-by: Kamal Heib <kheib@redhat.com> Link: https://patch.msgid.link/20260303043645.425724-1-kheib@redhat.com Reviewed-by: Siva Reddy Kallam <siva.kallam@broadcom.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-03-05xfs: Remove redundant NULL check after __GFP_NOFAILhongao
kzalloc() is called with __GFP_NOFAIL, so a NULL return is not expected. Drop the redundant !map check in xfs_dabuf_map(). Also switch the nirecs-sized allocation to kcalloc(). Signed-off-by: hongao <hongao@uniontech.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-03-05drm/ttm: Fix bo resource use-after-freeThadeu Lima de Souza Cascardo
When allocating a lot of buffers and putting the TTM under memory pressure, during swapout, it might crash the system with the stack trace below. It turns out that ttm_bo_swapout_cb might replace bo->resource when it moves it to system cached. When commit c06da4b3573a ("drm/ttm: Tidy usage of local variables a little bit") used a local variable for bo->resource, it used the freed resource later in the function, leading to a UAF. Move back to using bo->resource in all cases in that function instead of a local variable. [ 604.814275] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 604.814284] #PF: supervisor read access in kernel mode [ 604.814288] #PF: error_code(0x0000) - not-present page [ 604.814291] PGD 0 P4D 0 [ 604.814296] Oops: Oops: 0000 [#1] SMP NOPTI [ 604.814303] CPU: 2 UID: 0 PID: 4408 Comm: vulkan Tainted: G W 7.0.0-rc2-00001-gc50a051e6aca #21 PREEMPT(full) aef6eb0c02036a7c8a5e62e0c84a30c2be90688d [ 604.814309] Tainted: [W]=WARN [ 604.814311] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0133 08/05/2024 [ 604.814314] RIP: 0010:ttm_resource_move_to_lru_tail+0x100/0x160 [ttm] [ 604.814329] Code: 5b 5d e9 83 b4 1b cb 48 63 d2 48 c1 e0 04 48 8b 4e 40 48 8d 7e 40 48 8b ac d3 d8 00 00 00 48 89 c3 48 8d 54 05 68 48 8b 46 48 <48> 3b 38 0f 85 b3 3b 00 00 48 3b 79 08 0f 85 a9 3b 00 00 48 89 41 [ 604.814332] RSP: 0018:ffffcfe54e3d7578 EFLAGS: 00010256 [ 604.814336] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8cf09eced300 [ 604.814339] RDX: 0000000000000068 RSI: ffff8cf1d4c1fc00 RDI: ffff8cf1d4c1fc40 [ 604.814341] RBP: 0000000000000000 R08: ffff8cf09eced300 R09: 0000000000000000 [ 604.814344] R10: 0000000000000000 R11: 0000000000000016 R12: ffff8cf1d4c1fc00 [ 604.814346] R13: 0000000000000400 R14: ffff8cf096289c00 R15: ffff8cf084c8f688 [ 604.814349] FS: 00007f00531b7780(0000) GS:ffff8cf4217a0000(0000) knlGS:0000000000000000 [ 604.814352] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 604.814355] CR2: 0000000000000000 CR3: 000000018e3df000 CR4: 0000000000350ef0 [ 604.814358] Call Trace: [ 604.814362] <TASK> [ 604.814368] ttm_bo_swapout_cb+0x24c/0x280 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814380] ttm_lru_walk_for_evict+0xac/0x1d0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814394] ttm_bo_swapout+0x5b/0x80 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814405] ttm_global_swapout+0x63/0x100 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814415] ttm_tt_populate+0x82/0x130 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814424] ttm_bo_populate+0x37/0xa0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814433] ttm_bo_handle_move_mem+0x157/0x170 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814443] ttm_bo_validate+0xd9/0x180 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814453] ttm_bo_init_reserved+0xa0/0x1b0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.814461] ? srso_return_thunk+0x5/0x5f [ 604.814469] amdgpu_bo_create+0x1f5/0x500 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.814855] ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.815182] amdgpu_bo_create_user+0x3d/0x70 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.815504] amdgpu_gem_create_ioctl+0x16c/0x3b0 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.815830] ? __pfx_amdgpu_bo_user_destroy+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.816155] ? __pfx_amdgpu_gem_create_ioctl+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.816478] drm_ioctl_kernel+0xae/0x100 [ 604.816486] drm_ioctl+0x283/0x510 [ 604.816491] ? __pfx_amdgpu_gem_create_ioctl+0x10/0x10 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.816819] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.817135] __x64_sys_ioctl+0x96/0xe0 [ 604.817142] do_syscall_64+0x11b/0x7e0 [ 604.817148] ? srso_return_thunk+0x5/0x5f [ 604.817152] ? srso_return_thunk+0x5/0x5f [ 604.817156] ? walk_system_ram_range+0xb0/0x110 [ 604.817161] ? srso_return_thunk+0x5/0x5f [ 604.817165] ? __pte_offset_map+0x1b/0xb0 [ 604.817170] ? srso_return_thunk+0x5/0x5f [ 604.817174] ? pte_offset_map_lock+0x87/0xf0 [ 604.817179] ? srso_return_thunk+0x5/0x5f [ 604.817183] ? insert_pfn+0x9f/0x1f0 [ 604.817188] ? srso_return_thunk+0x5/0x5f [ 604.817192] ? vmf_insert_pfn_prot+0x97/0x190 [ 604.817197] ? srso_return_thunk+0x5/0x5f [ 604.817201] ? ttm_bo_vm_fault_reserved+0x1a6/0x3f0 [ttm a469cf7fcb6737fdcf3fb5cdbcc8b1ca41f3e302] [ 604.817213] ? srso_return_thunk+0x5/0x5f [ 604.817217] ? amdgpu_gem_fault+0xe2/0x100 [amdgpu 361516226706227f4403914dbfdd3f90996136ca] [ 604.817542] ? srso_return_thunk+0x5/0x5f [ 604.817546] ? __do_fault+0x33/0x180 [ 604.817550] ? srso_return_thunk+0x5/0x5f [ 604.817554] ? do_fault+0x178/0x610 [ 604.817559] ? srso_return_thunk+0x5/0x5f [ 604.817562] ? __handle_mm_fault+0x9be/0x1120 [ 604.817567] ? srso_return_thunk+0x5/0x5f [ 604.817574] ? srso_return_thunk+0x5/0x5f [ 604.817578] ? count_memcg_events+0xc4/0x160 [ 604.817583] ? srso_return_thunk+0x5/0x5f [ 604.817587] ? handle_mm_fault+0x1d7/0x2e0 [ 604.817593] ? srso_return_thunk+0x5/0x5f [ 604.817596] ? do_user_addr_fault+0x173/0x660 [ 604.817602] ? srso_return_thunk+0x5/0x5f [ 604.817607] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 604.817612] RIP: 0033:0x7f00532cef4d [ 604.817617] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 [ 604.817620] RSP: 002b:00007ffd69ab0650 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 604.817624] RAX: ffffffffffffffda RBX: 00007ffd69ab07d0 RCX: 00007f00532cef4d [ 604.817627] RDX: 00007ffd69ab0700 RSI: 00000000c0206440 RDI: 0000000000000005 [ 604.817629] RBP: 00007ffd69ab06a0 R08: 00007f00533a0ac0 R09: 0000000000000000 [ 604.817632] R10: 00007ffd69ab07c0 R11: 0000000000000246 R12: 00007ffd69ab0700 [ 604.817634] R13: 00000000c0206440 R14: 0000000000000005 R15: 0000000000000243 [ 604.817642] </TASK> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Fixes: c06da4b3573a ("drm/ttm: Tidy usage of local variables a little bit") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260304-ttm_bo_res_uaf-v1-1-43f20125b67f@igalia.com
2026-03-04Merge branch 'net-stmmac-fix-vlan-handling-when-interface-is-down'Jakub Kicinski
Ovidiu Panait says: ==================== net: stmmac: Fix VLAN handling when interface is down VLAN register accesses on the MAC side require the PHY RX clock to be active. When the network interface is down, the PHY is suspended and the RX clock is unavailable, causing VLAN operations to fail with timeouts. The VLAN core automatically removes VID 0 after the interface goes down and re-adds it when it comes back up, so these timeouts happen during normal interface down/up: # ip link set end1 down renesas-gbeth 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter renesas-gbeth 15c40000.ethernet end1: failed to kill vid 0081/0 Adding VLANs while the interface is down also fails: # ip link add link end1 name end1.10 type vlan id 10 renesas-gbeth 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter RTNETLINK answers: Device or resource busy Patch 4 fixes this by adding checks in the VLAN paths for netif_running(), and skipping register accesses if the interface is down. Only the software state is updated in this case. When the interface is brought up, the VLAN state is restored to hardware. Patches 1-3 fix some issues in the existing VLAN implementation. ==================== Link: https://patch.msgid.link/20260303145828.7845-1-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04net: stmmac: Defer VLAN HW configuration when interface is downOvidiu Panait
VLAN register accesses on the MAC side require the PHY RX clock to be active. When the network interface is down, the PHY is suspended and the RX clock is unavailable, causing VLAN operations to fail with timeouts. The VLAN core automatically removes VID 0 after the interface goes down and re-adds it when it comes back up, so these timeouts happen during normal interface down/up: # ip link set end1 down renesas-gbeth 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter renesas-gbeth 15c40000.ethernet end1: failed to kill vid 0081/0 Adding VLANs while the interface is down also fails: # ip link add link end1 name end1.10 type vlan id 10 renesas-gbeth 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter RTNETLINK answers: Device or resource busy To fix this, check if the interface is up before accessing VLAN registers. The software state is always kept up to date regardless of interface state. When the interface is brought up, stmmac_vlan_restore() is called to write the VLAN state to hardware. Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Link: https://patch.msgid.link/20260303145828.7845-5-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04net: stmmac: Fix VLAN HW state restoreOvidiu Panait
When the network interface is opened or resumed, a DMA reset is performed, which resets all hardware state, including VLAN state. Currently, only the resume path is restoring the VLAN state via stmmac_restore_hw_vlan_rx_fltr(), but that is incomplete: the VLAN hash table and the VLAN_TAG control bits are not restored. Therefore, add stmmac_vlan_restore(), which restores the full VLAN state by updating both the HW filter entries and the hash table, and call it from both the open and resume paths. The VLAN restore is moved outside of phylink_rx_clk_stop_block/unblock in the resume path because receive clock stop is already disabled when stmmac supports VLAN. Also, remove the hash readback code in vlan_restore_hw_rx_fltr() that attempts to restore VTHM by reading VLAN_HASH_TABLE, as it always reads zero after DMA reset, making it dead code. Fixes: 3cd1cfcba26e ("net: stmmac: Implement VLAN Hash Filtering in XGMAC") Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Link: https://patch.msgid.link/20260303145828.7845-4-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04net: stmmac: Improve double VLAN handlingOvidiu Panait
The double VLAN bits (EDVLP, ESVL, DOVLTC) are handled inconsistently between the two vlan_update_hash() implementations: - dwxgmac2_update_vlan_hash() explicitly clears the double VLAN bits when is_double is false, meaning that adding a 802.1Q VLAN will disable double VLAN mode: $ ip link add link eth0 name eth0.200 type vlan id 200 protocol 802.1ad $ ip link add link eth0 name eth0.100 type vlan id 100 # Double VLAN bits no longer set - vlan_update_hash() sets these bits and only clears them when the last VLAN has been removed, so double VLAN mode remains enabled even after all 802.1AD VLANs are removed. Address both issues by tracking the number of active 802.1AD VLANs in priv->num_double_vlans. Pass this count to stmmac_vlan_update() so both implementations correctly set the double VLAN bits when any 802.1AD VLAN is active, and clear them only when none remain. Also update vlan_update_hash() to explicitly clear the double VLAN bits when is_double is false, matching the dwxgmac2 behavior. Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Link: https://patch.msgid.link/20260303145828.7845-3-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04net: stmmac: Fix error handling in VLAN add and delete pathsOvidiu Panait
stmmac_vlan_rx_add_vid() updates active_vlans and the VLAN hash register before writing the HW filter entry. If the filter write fails, it leaves a stale VID in active_vlans and the hash register. stmmac_vlan_rx_kill_vid() has the reverse problem: it clears active_vlans before removing the HW filter. On failure, the VID is gone from active_vlans but still present in the HW filter table. To fix this, reorder the operations to update the hash table first, then attempt the HW filter operation. If the HW filter fails, roll back both the active_vlans bitmap and the hash table by calling stmmac_vlan_update() again. Fixes: ed64639bc1e0 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Link: https://patch.msgid.link/20260303145828.7845-2-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2026-03-03 (ice, libie, iavf, igb, igc) Larysa removes VF restriction for LLDP filters on ice to allow for LLDP traffic to reach the correct destination. Jakub adds retry mechanism for AdminQ Read/Write SFF EEPROM call to follow hardware specification on ice. Zilin Guan adds cleanup path to free XDP rings on failure in ice_set_ringparam(). Michal bypasses firmware logging unroll in libie when it isn't supported. Kohei Enju fixes iavf to take into account hardware MTU support when setting max MTU values. Vivek Behera fixes issues on igb and igc using incorrect IRQs when Tx/Rx queues do not share the same IRQ. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: igc: Fix trigger of incorrect irq in igc_xsk_wakeup function igb: Fix trigger of incorrect irq in igb_xsk_wakeup iavf: fix netdev->max_mtu to respect actual hardware limit libie: don't unroll if fwlog isn't supported ice: Fix memory leak in ice_set_ringparam() ice: fix retry for AQ command 0x06EE ice: reintroduce retry mechanism for indirect AQ ice: fix adding AQ LLDP filter for VF ==================== Link: https://patch.msgid.link/20260303231155.2895065-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04Merge branch 'mptcp-misc-fixes-for-v7-0-rc2'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: misc fixes for v7.0-rc2 Here are various unrelated fixes: - Patch 1: avoid bufferbloat in simult_flows selftest which can cause instabilities. A fix for v5.10. - Patches 2-3: reduce RM_ADDR lost by not sending it over the same subflow as the one being removed, if possible. A fix for v5.13. - Patches 4-5: avoid a WARN when using signal + subflow endpoints with a subflow limit of 0, and removing such endpoints during an active connection. A fix for v5.17. ==================== Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04selftests: mptcp: join: check removing signal+subflow endpMatthieu Baerts (NGI0)
This validates the previous commit: endpoints with both the signal and subflow flags should always be marked as used even if it was not possible to create new subflows due to the MPTCP PM limits. For this test, an extra endpoint is created with both the signal and the subflow flags, and limits are set not to create extra subflows. In this case, an ADD_ADDR is sent, but no subflows are created. Still, the local endpoint is marked as used, and no warning is fired when removing the endpoint, after having sent a RM_ADDR. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-5-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04mptcp: pm: in-kernel: always mark signal+subflow endp as usedMatthieu Baerts (NGI0)
Syzkaller managed to find a combination of actions that was generating this warning: msk->pm.local_addr_used == 0 WARNING: net/mptcp/pm_kernel.c:1071 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210, CPU#1: syz.2.17/961 Modules linked in: CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline] RIP: 0010:mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline] RIP: 0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210 Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP: 0018:ffffc90001663880 EFLAGS: 00010293 RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: <TASK> genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:742 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2592 ___sys_sendmsg+0x2de/0x320 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66346f826d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 </TASK> The actions that caused that seem to be: - Set the MPTCP subflows limit to 0 - Create an MPTCP endpoint with both the 'signal' and 'subflow' flags - Create a new MPTCP connection from a different address: an ADD_ADDR linked to the MPTCP endpoint will be sent ('signal' flag), but no subflows is initiated ('subflow' flag) - Remove the MPTCP endpoint In this case, msk->pm.local_addr_used has been kept to 0 -- because no subflows have been created -- but the corresponding bit in msk->pm.id_avail_bitmap has been cleared when the ADD_ADDR has been sent. This later causes a splat when removing the MPTCP endpoint because msk->pm.local_addr_used has been kept to 0. Now, if an endpoint has both the signal and subflow flags, but it is not possible to create subflows because of the limits or the c-flag case, then the local endpoint counter is still incremented: the endpoint is used at the end. This avoids issues later when removing the endpoint and calling __mark_subflow_endp_available(), which expects msk->pm.local_addr_used to have been previously incremented if the endpoint was marked as used according to msk->pm.id_avail_bitmap. Note that signal_and_subflow variable is reset to false when the limits and the c-flag case allows subflows creation. Also, local_addr_used is only incremented for non ID0 subflows. Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/613 Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-4-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04selftests: mptcp: join: check RM_ADDR not sent over same subflowMatthieu Baerts (NGI0)
This validates the previous commit: RM_ADDR were sent over the first found active subflow which could be the same as the one being removed. It is more likely to loose this notification. For this check, RM_ADDR are explicitly dropped when trying to send them over the initial subflow, when removing the endpoint attached to it. If it is dropped, the test will complain because some RM_ADDR have not been received. Note that only the RM_ADDR are dropped, to allow the linked subflow to be quickly and cleanly closed. To only drop those RM_ADDR, a cBPF byte code is used. If the IPTables commands fail, that's OK, the tests will continue to pass, but not validate this part. This can be ignored: another subtest fully depends on such command, and will be marked as skipped. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 8dd5efb1f91b ("mptcp: send ack for rm_addr") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-3-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04mptcp: pm: avoid sending RM_ADDR over same subflowMatthieu Baerts (NGI0)
RM_ADDR are sent over an active subflow, the first one in the subflows list. There is then a high chance the initial subflow is picked. With the in-kernel PM, when an endpoint is removed, a RM_ADDR is sent, then linked subflows are closed. This is done for each active MPTCP connection. MPTCP endpoints are likely removed because the attached network is no longer available or usable. In this case, it is better to avoid sending this RM_ADDR over the subflow that is going to be removed, but prefer sending it over another active and non stale subflow, if any. This modification avoids situations where the other end is not notified when a subflow is no longer usable: typically when the endpoint linked to the initial subflow is removed, especially on the server side. Fixes: 8dd5efb1f91b ("mptcp: send ack for rm_addr") Cc: stable@vger.kernel.org Reported-by: Frank Lorenz <lorenz-frank@web.de> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/612 Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-2-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04selftests: mptcp: more stable simult_flows testsPaolo Abeni
By default, the netem qdisc can keep up to 1000 packets under its belly to deal with the configured rate and delay. The simult flows test-case simulates very low speed links, to avoid problems due to slow CPUs and the TCP stack tend to transmit at a slightly higher rate than the (virtual) link constraints. All the above causes a relatively large amount of packets being enqueued in the netem qdiscs - the longer the transfer, the longer the queue - producing increasingly high TCP RTT samples and consequently increasingly larger receive buffer size due to DRS. When the receive buffer size becomes considerably larger than the needed size, the tests results can flake, i.e. because minimal inaccuracy in the pacing rate can lead to a single subflow usage towards the end of the connection for a considerable amount of data. Address the issue explicitly setting netem limits suitable for the configured link speeds and unflake all the affected tests. Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-1-4b5462b6f016@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04Merge branch 'nfc-fix-leaks-and-races-surfaced-by-nipa'Jakub Kicinski
Jakub Kicinski says: ==================== nfc: fix leaks and races surfaced by NIPA I recently added the nci test to NIPA. Somewhat surprisingly it runs without much settup but hits kmemleaks fairly often. Fix a handful of issues to make the test pass in a stable way. ==================== Link: https://patch.msgid.link/20260303162346.2071888-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04nfc: rawsock: cancel tx_work before socket teardownJakub Kicinski
In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. rawsock_tx_work runs on the system workqueue and calls nfc_data_exchange which dereferences the NCI device. Without synchronization, tx_work can race with socket and device teardown when a process is killed (e.g. by SIGKILL), leading to use-after-free or leaked references. Set SEND_SHUTDOWN first so that if tx_work is already running it will see the flag and skip transmitting, then use cancel_work_sync to wait for any in-progress execution to finish, and finally purge any remaining queued skbs. Fixes: 23b7869c0fd0 ("NFC: add the NFC socket raw protocol") Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260303162346.2071888-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04nfc: nci: clear NCI_DATA_EXCHANGE before calling completion callbackJakub Kicinski
Move clear_bit(NCI_DATA_EXCHANGE) before invoking the data exchange callback in nci_data_exchange_complete(). The callback (e.g. rawsock_data_exchange_complete) may immediately schedule another data exchange via schedule_work(tx_work). On a multi-CPU system, tx_work can run and reach nci_transceive() before the current nci_data_exchange_complete() clears the flag, causing test_and_set_bit(NCI_DATA_EXCHANGE) to return -EBUSY and the new transfer to fail. This causes intermittent flakes in nci/nci_dev in NIPA: # # RUN NCI.NCI1_0.t4t_tag_read ... # # t4t_tag_read: Test terminated by timeout # # FAIL NCI.NCI1_0.t4t_tag_read # not ok 3 NCI.NCI1_0.t4t_tag_read Fixes: 38f04c6b1b68 ("NFC: protect nci_data_exchange transactions") Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260303162346.2071888-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04nfc: nci: complete pending data exchange on device closeJakub Kicinski
In nci_close_device(), complete any pending data exchange before closing. The data exchange callback (e.g. rawsock_data_exchange_complete) holds a socket reference. NIPA occasionally hits this leak: unreferenced object 0xff1100000f435000 (size 2048): comm "nci_dev", pid 3954, jiffies 4295441245 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc ec2b3c5): __kmalloc_noprof+0x4db/0x730 sk_prot_alloc.isra.0+0xe4/0x1d0 sk_alloc+0x36/0x760 rawsock_create+0xd1/0x540 nfc_sock_create+0x11f/0x280 __sock_create+0x22d/0x630 __sys_socket+0x115/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0x117/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: 38f04c6b1b68 ("NFC: protect nci_data_exchange transactions") Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260303162346.2071888-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-04nfc: digital: free skb on digital_in_send error pathsJakub Kicinski
digital_in_send() takes ownership of the skb passed by the caller (nfc_data_exchange), make sure it's freed on all error paths. Found looking around the real driver for similar bugs to the one just fixed in nci. Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support") Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260303162346.2071888-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-15 10:42:56 +0000