Add a detailed explanation how the hardware polling unit in the
Realtek Otto switches works. This simplifies developing future
patches and reviewing them.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-3-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The lower end Realtek Otto switches provide 1G only and are divided into
two series:
- Maple : RTL838x up to 28 ports
- Cypress: RTL839x up to 52 ports
The Maple based devices have 3 different SoCs: RTL8380, RTL8381 and
RTL8382. The Cypress series consists of the RTL8391, RTL8392 and
RTL8393 SoCs. The MDIO controller of these switches works like the
existing RTL93xx logic but has different characteristics and different
registers. Add new compatibles in the device tree.
With the extended compatibility list change the title to better reflect
its scope. Especially add the "Ethernet" tag as these devices have
multiple MDIO controllers.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260831143439.2404484-2-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Mike Rapoport says:
====================
USB: replace page allocator calls with kmalloc()
This is a (small) part of larger work of replacing page allocator calls
with kmalloc.
My initial intention a few month ago was to remove ugly casts [1], but then
willy pointed out that Linus objected to something like this [2] and it
looks like more than a decade old technical debt.
Largely, anything that doesn't need struct page (or a memdesc in the
future) should just use kmalloc() or kvmalloc() to allocate memory.
kmalloc() guarantees alignment, physical contiguity and working
virt_to_phys() and beside nicer API that returns void * on alloc and
doesn't require to know the allocation size on free, kmalloc() provides
better debugging capabilities than page allocator.
Another thing is that touching these allocation sites gives the reviewers
opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
another size is appropriate.
For larger allocations that don't need physically contiguous memory
kvmalloc() can be a better option that __get_free_pages() because under
memory pressure it's is easier to allocate several order-0 pages than a
physically contiguous chunk with the same number of pages.
And last, but not least, removing needless calls to page allocator should
help with memdesc (aka project folio) conversion. There will be way less
places to audit to see if the user was actually using struct page.
The patches are deliberately kept small: each one deals with a single
driver or subsystem and with a single type of allocation, so that every
conversion can be reviewed, and if needed reverted, on its own.
====================
Link: https://patch.msgid.link/20260830-usb-v1-0-aa349c302246@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
speedtch_upload_firmware() allocates a temporary buffer used to feed the
firmware to the device.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260830-usb-v1-3-aa349c302246@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
cxacru_fw() allocates a temporary buffer used to feed the firmware to the
device and cxacru_bind() allocates the transfer buffers for the command
URBs.
These buffers can be allocated with kmalloc() as there's nothing special
about them to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260830-usb-v1-2-aa349c302246@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 71338aa7d0 ("net: convert %p usage to %pK") which is from
2011 and changed the %p annotation for pointer to %pK. Back then the
default behaviour for %p was to print the pointer. The %pK modifier was
introduced to able to control the behaviour of specific pointer values
without changing the behaviour of %p for everyone. It was dedicated to
avoid leaking pointers via /proc.
There was also the idea to remove the check from formatting the string
and move to the open callback with some helpers but this did not happen.
Things changed over time. The default behaviour for %p is now to print a
hash pointer which does not leak the address but allows to correlate if
two pointers are equal.
The policy on %p is to not introduce new ones. This is somehow in
between since it already exists. The pointer are usually socket pointers
and I don't see any value in exposing them. Therefore I am following the
recommendation of removing them. Since their usage in /proc/ can be
considered ABI I replace the pointer with a 0.
Replace the %pK annotation with 0 value. Correct the spacing for the
cases where pointer is at the beginning.
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://patch.msgid.link/20260901160345.eeknHmY2@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A netdevsim VF port cannot process incoming data. It never runs
nsim_queue_init(), so ns->rq is NULL, and nsim_vf_netdev_ops has no
->ndo_open, so its NAPI is never set up either.
nsim_setup() offers NETIF_F_LOOPBACK to both PF and VF ports. Turning
it on for a VF makes nsim_start_xmit() take ns itself as peer_ns and
dereference peer_ns->rq[], which panics.
A VF cannot deliver packets at all: it can't be linked as a peer either,
since netdev_is_nsim() only matches the PF netdev_ops, so ns->peer is
always NULL and every skb ends up dropped. Give VF ports a dedicated
xmit that just drops the traffic, so VFs no longer depend on PF-only
state in nsim_start_xmit().
Reproduce in qemu:
modprobe netdevsim
echo "90 1" > /sys/bus/netdevsim/new_device
echo 2 > /sys/bus/netdevsim/devices/netdevsim90/sriov_numvfs
devlink dev eswitch set netdevsim/netdevsim90 mode switchdev
ethtool -K eth2 loopback on # eth2 is the vfnum 0 port
ip link set eth2 up
Panic:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 141 Comm: kworker/0:3 Not tainted 7.2.0+ #338 PREEMPT
Workqueue: mld mld_ifc_work
RIP: 0010:nsim_start_xmit (drivers/net/netdevsim/netdev.c:159)
dev_hard_start_xmit ( net/core/dev.c:3953)
sch_direct_xmit (net/sched/sch_generic.c:372)
__dev_queue_xmit (net/core/dev.c:4262 net/core/dev.c:4884)
neigh_resolve_output (net/core/neighbour.c:1616)
ip6_finish_output2 (net/ipv6/ip6_output.c:138)
ip6_finish_output (net/ipv6/ip6_output.c:221)
ip6_output (net/ipv6/ip6_output.c:248)
......
Cc: stable+noautosel@kernel.org # netdevsim is a test harness, it's never loaded on production systems
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260901061851.61734-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski says:
====================
selftests: drv-net: split up gro.py
gro.py runs its full set of cases three times over - against SW GRO,
HW GRO and LRO. It's our test with the longest runtime. The 318 cases
take 12m30s on mlx5 with a debug kernel.
We will likely add more subcases here as the time goes on, so it's
time to start splitting it up. Long runtime wastes time on retries
(if any of the 300+ cases fails we try to check if it's a real failure
or flake an re-run the whole thing). It also forces us to increase
timeout for the whole test suite.
v1: https://lore.kernel.org/20260831163734.1121891-1-kuba@kernel.org
====================
Link: https://patch.msgid.link/20260901200728.2063720-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The XDP test takes 9m30s on the slowest NIC with debug kernel.
Let's give ourselves a 50% margin and set the timeout to 15min.
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260901200728.2063720-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gro.py runs its full set of cases three times over - against SW GRO,
HW GRO and LRO. It's our test with the longest runtime. The 318 cases
take 12m30s on mlx5 with a debug kernel.
Bumping the timeout for all tests feels wrong when we can so easily
split the GRO test by execution mode. Shorter runtime also helps retry
just the failing portion / mode (we retry failing tests to try to
detect flakes vs real failures).
Move the main logic to gro_lib.py and add one program per mode -
gro_sw.py, gro_hw.py and gro_lro.py, 102 cases each. Move PPPoE to
a dedicated test. It has been tacked onto the tests in an ugly way,
and it only runs against SW GRO anyway.
Note that unfortunately this will case a rename of all test cases.
The mode moves from the case name to the test name
gro.py test.sw_ipv4_data_same
becomes
gro_sw.py test.ipv4_data_same
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260901200728.2063720-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We need to free up the gro_hw.py name for the HW-GRO half of gro.py,
which we need to split by mode (sw / hw / lro). The file checks mostly
qstat counters, so name it after stats.
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260901200728.2063720-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The binding references ethernet-controller.yaml schema, which already
defines a dependency of pcs-handle-names on pcs-handle, thus duplicating
it here is redundant.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260901061255.25734-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Oleksij Rempel says:
====================
net: dsa: realtek: enable RTL8365MB power supplies
The RTL8365MB family has several external power rails (analog, digital I/O
and PLL supplies) that on some boards are gated by regulators. Until now the
driver assumed they were always on, so it could not be used on designs that
keep these rails software-controlled.
This series adds a device-tree description for those supplies and enables
them in the driver before the chip is accessed:
The supplies are optional: boards that hard-wire the rails work unchanged
====================
Link: https://patch.msgid.link/20260831123637.666457-1-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace the open-coded dev_err() + ERR_CAST() on the reset GPIO error
path with dev_err_cast_probe(), matching the reset controller above and
staying quiet on -EPROBE_DEFER.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260831123637.666457-4-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The power supplies powering the IC may not necessarily be enabled by the
time the driver probes. The binding describes the power rails, so enable
them at probe with devm_regulator_bulk_get_enable(), before the reset line
is requested and driven, so the chip is powered before its pins are driven.
Boards that do not describe these supplies fall back to dummy regulators
(with a "supply not found" warning) and keep working as before.
A board that describes supplies but no reset line still needs to wait for
the chip to boot before the first register access, so apply the existing
start delay in that case too.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260831123637.666457-3-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Document the RTL8365MB power rails as optional supplies. They are optional
because the rails are often always-on; some designs break them out for
granular hwmon monitoring and regulator control.
They are scoped to realtek,rtl8365mb: different Realtek switch families use
different power-rail naming schemes, so these rails do not apply to other
families such as realtek,rtl8366rb (VDDA/VDD_CORE/VDDIO/...).
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260831123637.666457-2-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hangbin Liu says:
====================
bonding: fix TLB load-tracking overflow on high-speed NICs
The bonding TLB (Transmit Load Balancing) mode tracks per-slave and
per-client transmit byte counts in u32 fields. At sustained throughput
above ~3.2 Gbit/s over the 10-second rebalance interval these counters
wrap, causing compute_gap() to produce incorrect gap values and
mis-select transmit slaves. Such speeds are routine on modern NICs
under heavy traffic.
This two-patch series fixes the overflow by widening the relevant
fields to u64.
Patch 1 converts the unbalanced_load counter to per-cpu state as a
preparatory step. The counter sits in the transmit hot path, so
converting it to per-cpu before widening avoids introducing cross-CPU
synchronization overhead for a u64. Also use a prev_total_unbalanced
to store the previous total load to avoid reset per-cpu data.
Patch 2 widens tx_bytes, load_history, load, and the per-cpu
unbalanced_load tx_bytes from u32 to u64. It adds u64_stats_sync
protection for the per-cpu counter to prevent tearing on 32-bit
architectures, and reworks compute_gap() to use s64 arithmetic with
READ_ONCE() on slave->speed.
====================
Link: https://patch.msgid.link/20260831-bond_overflow-v6-0-ffb0ed1f7268@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The TLB load-tracking fields tx_bytes, load_history, load, and
unbalanced_load are all u32. At sustained throughput above ~3.2 Gbit/s
over the 10-second rebalance interval the byte counters wrap, causing
compute_gap() to produce incorrect gap values and mis-select slaves.
Such speeds are common on modern NICs under heavy traffic.
Widen these fields to u64. Use u64_stats_sync to protect the per-cpu
unbalanced_load_stats against tearing on 32-bit architectures, and
div_u64() for the 64-bit divisions. The tx_bytes and load_history
are protected in spin_lock. Also protect the slave load writing in
bond_alb_monitor() with spin_lock in case of tear on 32-bit.
For compute_gap(), we still use s64 arithmetic throughout, so we can
preserve the existing calculation logic. This order of magnitude is
sufficiently large, there is no need to worry about overflow for now.
Detected by AI code review.
Cc: stable+noautosel@kernel.org # never worked
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Acked-by: Jay Vosburgh <jv@jvosburgh.net>
Link: https://patch.msgid.link/20260831-bond_overflow-v6-2-ffb0ed1f7268@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A later patch widens the bonding TLB tx counters from u32 to u64. The
unbalanced_load counter sits in the transmit hot path, and cross-CPU
synchronization of a u64 would introduce measurable overhead. Convert
unbalanced_load to a per-cpu counter first so that the subsequent
widening only touches per-cpu data local to each CPU.
Introduce struct unbalanced_load_stats to hold the per-cpu counter,
and move the aggregation into a helper, reset_unbalanced_load(), which
sums all per-cpu instances. Use the delta of current total load vs
variable prev_total_unbalanced to calculate the loading.
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Acked-by: Jay Vosburgh <jv@jvosburgh.net>
Link: https://patch.msgid.link/20260831-bond_overflow-v6-1-ffb0ed1f7268@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This basically reverts the Feb 2021 change:
commit 96854bbda2 ("hv_netvsc: Restrict configurations on isolated guests")
In Feb 2021, PCI device assignment for CoCo VMs on Hyper-V was not
supported: if the host offered a PCI VF NIC device to the VM, the VM
couldn't handle it properly, so the 2021 commit was made to tell the host
"I'm unable to handle SR-IOV NICs, so please don't offer a VF to me".
If the host offers a VF NIC to the VM anyway, the change to
netvsc_receive_inband() ignores the VF NIC.
Since Mar 2023, the VM is able to support PCI device assignment due to
commit 2c6ba42168 ("PCI: hv: Enable PCI pass-thru devices in Confidential VMs")
and related commits, so hv_netvsc can functionally work with a VF NIC, but
we haven't advertised the SR-IOV capability because the MANA NIC driver
(drivers/net/ethernet/microsoft/mana/) hadn't been hardened, so a
malicious MANA NIC might be able to attack the VM.
Recently, we have finished hardening the MANA driver, so we can safely
use the MANA NIC in a CoCo VM now. Note: currently the MANA driver in a
CoCo VM still uses bounce buffering (i.e. shared decrypted memory)
for DMA. In the future, it will be able to use private encrypted
memory for DMA with the help of TDISP.
Now, advertises the SR-IOV capability for CoCo VMs.
Note: for MANA to work properly for CoCo VMs, the following earlier
commits are also required:
commit 2e2a83b499 ("net: mana: Validate the packet length reported by the NIC")
commit c72a0f09c5 ("net: mana: Sync page pool RX frags for CPU")
Note: the host might offer a VF NIC device that's not MANA -- in that
case, if the corresponding VF NIC driver isn't hardened for CoCo VMs,
the driver should be blacklisted in CoCo VMs.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The mailbox path warns when a message claims more bytes than the descriptor
but still parses it. The attribute walkers also validate a child TLV before
proving that its declared span fits in the parent remainder.
Reject invalid mailbox message extents and bound each child attribute
before type-specific validation.
Cc: stable+noautosel@kernel.org # assumes malicious PCIe device
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260830142516.38145-1-pengpeng@iscas.ac.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Sitnicki says:
====================
net: Prepare skb extensions for reuse across scrubs
Following Florian's suggestion from the discussion in [1].
The skb extension allocator retains the extension's offset after the
extension is deleted. This, in theory, allows skb_ext_add() to reuse the
existing storage instead of appending another copy when an extension is
added again. However, it also means that we can't rely on the offset as an
indicator that the extension is present.
Make the extension cleanup safe, even when the offset is already allocated
and set, by making the individual extension put helpers idempotent, so that
they can be called multiple times.
This is preparatory work to support skb extension chunk area reuse after
skb scrubbing, which would be needed to persist BPF metadata skb extension
across scrubs [2].
[1] https://lore.kernel.org/ao9UV9S7rUkyQ8jv@strlen.de
[2] https://lore.kernel.org/64365932-c765-472e-bf6c-b07c9ee25eaf@kernel.org
====================
Link: https://patch.msgid.link/20260831-skb-ext-prep-work-v1-0-ecc2a8542fd9@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MCTP flow extension can be released either when it is deleted from an
skb or when the last skb holding the extension block is freed. Handle the
release in __skb_ext_del(), which is currently missing, and make
skb_ext_put_mctp() safe to call from both paths.
This will let __skb_ext_put() release the MCTP key without checking whether
the extension is present first, which is needed if we want to reuse skb_ext
chunks area after skb scrubbing.
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Acked-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260831-skb-ext-prep-work-v1-2-ecc2a8542fd9@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The sec_path extension can be released either when it is deleted from an
skb or when the last skb holding the extension block is freed. Make
skb_ext_put_sp() safe to call from both paths by returning when
sec_path->len is zero and clearing it after dropping the XFRM state
references.
This will let __skb_ext_put() release the sec_path without checking whether
the extension is present first, which is needed if we want to reuse skb_ext
chunks area after skb scrubbing.
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://patch.msgid.link/20260831-skb-ext-prep-work-v1-1-ecc2a8542fd9@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add missing enum member force-forwarding to ipv6-devconf.
In commit f24987ef69 ("ipv6: add `force_forwarding` sysctl to
enable per-interface forwarding"), the DEVCONF_* enum was extended
with DEVCONF_FORCE_FORWARDING, however Gabriel forgot to add it
to the spec.
This pre-existing issue was detected by Sashiko, when reviewing the
first patch in this series.
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824103816.40040-1-ast%40fiberby.net
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://patch.msgid.link/20260831093458.472180-4-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add missing enum member accept-ra-min-lft to ipv6-devconf.
In commit 1671bcfd76 ("net: add sysctl accept_ra_min_rtr_lft")
the DEVCONF_* enum was extended with DEVCONF_ACCEPT_RA_MIN_RTR_LFT.
It was renamed to DEVCONF_ACCEPT_RA_MIN_LFT in commit 5027d54a9c
("net: change accept_ra_min_rtr_lft to affect all RA lifetimes").
Shortly thereafter, this spec was introduced in commit b2f63d904e
("doc/netlink: Add spec for rt link messages").
This pre-existing issue was detected by Sashiko, when reviewing the
first patch in this series.
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824103816.40040-1-ast%40fiberby.net
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20260831093458.472180-3-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
devconf is even odder than described in commit 720447bd0b
("netlink: specs: rt-link: remove implicit structs from devconf"),
where both IPv4 and IPv6 are described in an identical way:
"u32 indexed by ipv?-devconf - 1 on output, on input it's a nest".
There are two issues with that line for IPv6:
1) The subtraction is an IPv4 specific quirk, to avoid having an unused
u32 at index 0, thus saving 4 bytes per net device being dumped:
- In include/uapi/linux/ip.h the IPV4_DEVCONF_* enum begins with
IPV4_DEVCONF_FORWARDING = 1, so the enum starts at 1, which is
the reason for the subtraction in the IPv4 variant.
- In include/uapi/linux/ipv6.h the DEVCONF_* enum begins with
DEVCONF_FORWARDING = 0, so subtraction would underflow.
- ipv6_store_devconf() in net/ipv6/addrconf.c also doesn't do the
subtraction in the output path.
2) Setting IPv6 devconf through Netlink is not yet supported, as
IFLA_INET6_CONF is not handled in inet6_set_link_af().
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Link: https://patch.msgid.link/20260831093458.472180-2-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
dwmac can do ARP offloading, where the HW replies to incoming ARP
requests. This requires multiple steps to work well :
- Program the local IP address in a dedicated register
- Enable ARP offloading
This is halfway implemented in stmmac, as it's only ever used by
selftests, and these selftests are failing on at least 2 platforms :
stm32mp1, and jh7110.
There have been some attempts in the past to support this feature, but
this never made it upstream. Let's just remove the test and that code,
until someone actually wants that to work. We should likely have a
proper API for that so that drivers can use it.
Let's also not mention ARP offload in the stmmac documentation.
Leave the defines in place and the capability detection, this doesn't
hurt and gives some information about how the IP is synthesized.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260831071351.354255-1-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In __stmmac_open() and stmmac_xdp_open(), the DMA engine is started
before stmmac_request_irq() is called. If the IRQ request fails, the
clean-up paths free the DMA descriptor rings via dma_free_coherent()
without stopping the DMA engine first.
With the DMA engine still running, hardware may continue to access the
descriptor ring memory after it has been freed. Add stmmac_stop_all_dma()
to both error paths, matching the teardown order in __stmmac_release().
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
Link: https://patch.msgid.link/32EB352EB66D74E7+20260827025415.2684733-1-zhaojinming@uniontech.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Xuanqiang Luo says:
====================
net: phy: fix cleanup after probe failure
phy_probe() initializes the PHY driver, ports, SFP upstream, and LEDs in
stages. Its error paths do not always release only the resources acquired
at each stage. It can also mark the PHY ready before all setup succeeds.
Port setup also leaves SFP cleanup split between phy_sfp_probe(),
phy_setup_ports(), and phy_probe(), and default port setup ignores errors
from attaching the port to the PHY driver.
This series makes each initialization layer own its cleanup and propagates
setup failures to the caller.
Patch 1 splits the phy_probe() cleanup by initialization stage.
Patch 2 makes SFP and port setup unwind their resources in the required
order.
Patch 3 sets PHY_READY only after LED setup succeeds.
Patch 4 calls the PHY driver remove callback after later probe failures.
Patch 5 propagates errors from default port setup.
Patch 6 prevents a double-free after partial LED trigger registration.
====================
Link: https://patch.msgid.link/20260823035600.188864-1-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_led_triggers_register() frees phy_led_triggers when a speed trigger
registration fails, but leaves the pointer set to the freed allocation
before clearing phy_num_led_triggers.
phy_probe() ignores the registration error. If a later probe step fails,
its error path calls phy_led_triggers_unregister(); normal teardown during
an unbind or MDIO bus removal calls the same helper from phy_remove().
In either case, the trigger count is zero, so the per-trigger unregister
loop is skipped, but the dangling pointer is still freed unconditionally.
Clear the pointer when partial registration cleanup frees the array, and
make phy_led_triggers_unregister() free the array only when its pointer is
non-NULL.
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-7-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_default_setup_single_port() ignores errors from phy_add_port() and
always reports success. If a PHY driver attach_mdi_port() callback fails,
the phy_port is leaked and PHY probing continues without the expected
default port.
Destroy the port and return the error.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-6-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_probe() may fail while querying features or completing other core
initialization after the PHY driver probe callback has succeeded. The
driver core does not run the remove path after a probe error, so
resources that the PHY driver releases in its remove callback are
leaked.
Call the PHY driver remove callback on these failures.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-5-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_probe() sets PHY_READY before calling of_phy_leds(). If LED setup
fails, the error path releases the initialized resources while the PHY
state remains READY even though probing failed.
Set PHY_READY only after LED setup succeeds.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-4-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 4497f50286 ("net: phy: Clean the phy_ports after unregistering
the downstream SFP bus") established that an SFP upstream must be
unregistered before its phy_ports are destroyed because SFP callbacks
may access these ports.
phy_setup_ports() does not follow this order when a later port setup
step fails after phy_sfp_probe() succeeds. It destroys the SFP phy_port
and leaves phy_probe() to unregister the upstream later, creating a race
between port destruction and SFP upstream callbacks.
The error unwind is also split across three functions. If
phy_setup_sfp_port() fails, phy_sfp_probe() leaves the upstream
registered and relies on phy_probe() to remove it after
phy_setup_ports() returns.
Make each layer unwind the resources it successfully set up. Unregister
only the upstream in phy_sfp_probe() when SFP port setup fails, since
the failed port has already been destroyed. Add phy_sfp_release() for a
successful SFP probe, and make phy_setup_ports() use it before cleaning
up the remaining ports. Once phy_setup_ports() has rolled back all port
setup, make phy_probe() skip this cleanup.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-3-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_probe() uses one cleanup path for failures at every initialization
stage. This runs cleanup for resources that have not been initialized.
After a successful probe and remove, phy_led_triggers_unregister() can
leave phy_num_led_triggers non-zero after freeing the trigger array. If a
subsequent probe fails before LED trigger registration, the common error
path calls phy_led_triggers_unregister() with a NULL array and stale count,
causing a NULL dereference.
Split the cleanup by initialization stage so each failure path unwinds only
the resources that may have been initialized. Unregister LED triggers
before releasing the SFP upstream and ports, because the LED triggers are
initialized after those resources and must be unwound first.
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-2-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Current release - fix to a fix:
- netfilter: ipset: remove need to allocate memory on delete operations
Current release - regressions:
- macb: drop CONFIG_OF #if block, fix build
Previous releases - always broken:
- stream of fixes for SCTP continues
- inet: frags: strip GSO state from fragments before reassembly
- virtio-net: ensure that TCP packets don't overflow gso_segs
- tcp-ao: fix use-after-free of current_key on reconnect to another peer
- page_pool: remove zone/policy GFP flags when allocating XArray entries
- Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
- tls: device: fix out-of-bounds write in tls_append_frag()
- eth: bnxt:
- ring the doorbell when SW USO exits early, avoid packets stuck in Tx
- gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check, avoid users
of older NICs seeing non-actionable warning messages
- eth: qede: fix NULL pointer dereference in TPA fragment processing
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6jPA+I1ugmIBA4hXMUZtbf5SIrsFAmqQojwACgkQMUZtbf5S
Irv2kg//anC58qIya/Tx3BZkpPgtbS+ki0bqb+J0a8axbItgSGEdclVtiLJn/ex0
zz9AR4Pt2DSbSUHPa7nRpdMQ2x7ZmNwNR2zqs1xClgOm5QD/2JAc53Pv81GaEKa4
O4A4TDJZfyTDsk6c0cjI3yz9uMqBt2U6pyAT6JMBIPy7/MgV+as0ETAWQlezL0sF
ZnXVg9tM3hG/8a3M88+/S1VODVJYLMucXS6pD1mqlry01SUj91elEXKiac5vCaHI
DAZaiCOmv4WV3hs7941VijPchLO64L0J+0qjGRpXiPJXQEAn4XU8QX/YNc1njgZH
tmjRWEEtLoBFcLRDUPAK9niuB5F9N3/6nnydLPLu16+exKQuCB8Bh78YHLmlrJIW
utY5ek7GtPOl31M9a5TdEGLUg5wPHSO62FhiBmTiIG4PKQym616TmOHbYJWBqFry
EPNtZ1vEJoPFNOsT1VdeD4DKVBq2UDnj/3fnphUhfvU5z+dEDdIn03+kQykwmVQT
kTuMaW4/zxR3VFjHalsI+4bvhFOEmu+/KZE07aKKm99jssDsewQHGXgYJkCPWQUk
gpnN8IVNw16ex9sfrvqje6/tshiPJJn9y/b/nGt5mq9ofgwXGmpzCPwcDgyzZKQ5
y+zVPJ0/XILHAHOBxdCklim5xiaPDYKdEI+zcEXrx/g6FraZZuI=
=1DXR
-----END PGP SIGNATURE-----
Merge tag 'net-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from Bluetooth, IPSec and Netfilter.
Current release - fix to a fix:
- netfilter: ipset: remove need to allocate memory on delete operations
Current release - regressions:
- macb: drop CONFIG_OF #if block, fix build
Previous releases - always broken:
- stream of fixes for SCTP continues
- inet: frags: strip GSO state from fragments before reassembly
- virtio-net: ensure that TCP packets don't overflow gso_segs
- tcp-ao: fix use-after-free of current_key on reconnect to another
peer
- page_pool: remove zone/policy GFP flags when allocating XArray
entries
- Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
- tls: device: fix out-of-bounds write in tls_append_frag()
- eth: bnxt:
- ring the doorbell when SW USO exits early, avoid packets stuck
in Tx
- gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check, avoid
users of older NICs seeing non-actionable warning messages
- eth: qede: fix NULL pointer dereference in TPA fragment processing"
* tag 'net-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (216 commits)
inet: frags: strip GSO state from fragments before reassembly
net/sched: sch_htb: limit htb_classify inner-class filter hops
selftests/net: packetdrill: add tcp_urg_ptr_retransmit
tcp: fix corruption of urgent data on multi-segment retransmit
usb: atm: usbatm: fix invalid ci_range initialization
net: fec: only stop PTP if it was initialized
slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()
net: bridge: mcast: fix use-after-free of a master VLAN's multicast context
net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup
net: dsa: mxl862xx: enable assisted learning on CPU port
net: stmmac: restore NET_IP_ALIGN in the RX DMA offset
net: stmmac: drop gso_enabled_types and rely on netdev features
net: stmmac: selftests: Don't test flow control for small rx fifos
net: stmmac: selftests: Account for the UC filter list for filtering tests
net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering
net: stmmac: dwmac4: Account for the primary MAC address for UC filtering
net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering
net: stmmac: selftests: Check multiple MMC counters
selftests: net: Fix slow configurations in big_tcp_tunnels.sh
selftests: net: Lower threshold with csum offload off in big_tcp_tunnels.sh
...
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEjF9xRqF1emXiQiqU1w0aZmrPKyEFAmqQRZIACgkQ1w0aZmrP
KyGDXw/9G1jVJaet7bUaiAkQRIFgyarOE7VZXtUcKpxXfRBBghWfyEN3AO9VTuVj
/tQBwZUGWZnSrBOaLlTS95xD7A3TX+iQ9aMagiH6tVXGDRq3tQFxZim4BP7drdl8
R6DV1VwwHHQSeb3vMTcXPCK/W1RtMrhdkJOe8olxHp7KAfrnJl7YANdwT508PAh3
D4Wn0NWQrneEfwe31p7weMQy+w9sh5qSPb3petdwI7an9gCwhiovEtkF0X0EfkbK
OMorNc/dx56cabwI+U0y2LGn+4lJTz8U5+Z9S/KI1+x/vo1pkeeyEN5jdq9Jcuf/
Y7q08n1DbBrbbXehfe0u22ttVaENarf7SJhduw4nEOw4oIngfET/FNMbcfsj1uw4
CvRwL5hV+waI2taOdw4M1MJh0W3qU/IN+dhhigcseAacneoGULOWT9+rynNM/yKe
cfxmtFU7TFbp9L9tX6/NR1rs6Bv7oAFv98sjsGsdyhxsIZONm/KhX+CYNKfkOZmV
o8x198CR68Vb+aQTJFL6wJuX9lntMoXjazBYKQxGnzoShywsIKnOKHkvcRMofyT0
pgzXxlt9W94fnWmxwLoCdhedQjipb0GwG4pSm425nLz8GHOX+Gh+2oFayfzC6kvB
Gj41ozdfM1VQ0SI6fRr+GA2zQNIBzAQTtwT9y6VVK10ZFyR0fwU=
=Wak/
-----END PGP SIGNATURE-----
Merge tag 'nf-26-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Use DEBUG_NET_WARN_ON_ONCE() instead of WARN_ON() from the tproxy
datapath, a recent bug found a way to reach WARN_ON from datapath
due to insufficient validation of xt_TPROTO checkentry.
From Fernando F. Mancera.
2) Similar to previous patch to replace WARN_ON_ONCE by
DEBUG_NET_WARN_ON_ONCE() for connlimit. Not known issue, but
since this patch has been around for a while, let's merge it.
Also from Fernando.
3) Move nf_tables harware offload commit path after chain blob
and audit to reduce chances of leaving the hardware in
inconsistent state.
4) Add missing vzeroupper to nf_tables pipapo AVX2 to address
performace degradation to later user of SSE code,
from Eric Biggers.
5) Remove pr_debug() in x_tables extensions, a recent bogus found a
way to print a unsanitized string in xt_IDLETIMER, many of these
pr_debug() calls are there for historical reasons.
6) Use pr_info_ratelimited() in x_tables .checkentry.
7) Fix an imbalance in module refcount due to incorrect override
expression logic with sets. Remove unnecessary clone in control
plane, use the existing expressions provided by set or dynset
expression. Release override expressions only.
8) Tigthen nf_tables device name removal, it is possible to remove
prefix strings with exact device name. From Fernando F. Mancera.
9) Set on the set dead bit earlier, otherwise it is possible to
call .commit on deleted sets. This also addresses the
re-introduction of a bug.
* tag 'nf-26-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: nf_tables: remove leftover set_update_list
netfilter: nf_tables: set on dead bit when performing early element removal
netfilter: nf_tables: skip double clone set expressions on element insert
netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()
netfilter: x_tables: remove pr_debug
netfilter: nft_set_pipapo_avx2: add missing vzeroupper
netfilter: nf_tables: move hardware offload step after building the chain blob
netfilter: conncount: use DEBUG_NET_WARN_ON_ONCE on reaching count limit
netfilter: tproxy: use DEBUG_NET_WARN_ON_ONCE for protocol fallbacks
====================
Link: https://patch.msgid.link/20260827141733.423453-1-pablo@netfilter.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark
an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off.
inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first
fragment's skb as the head of the reassembled datagram, including its
shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments
on frag_list with whatever linear/paged layout they arrived with.
After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the
reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and
the next software segmentation point - udp_rcv_segment() on local
delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow
path - hands it to skb_segment(). skb_segment()'s frag_list walk
assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to
a tap by an unprivileged user in its own userns are enough:
kernel BUG at net/core/skbuff.c:4899!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2
RIP: 0010:skb_segment+0x20ca/0x48b0
Call Trace:
<TASK>
__udp_gso_segment+0x29a/0x27d0
udp4_ufo_fragment+0x458/0x6c0
inet_gso_segment+0x429/0x1340
skb_mac_gso_segment+0x233/0x4f0
__skb_gso_segment+0x308/0x660
udp_queue_rcv_skb+0x440/0xad0
udp_unicast_rcv_skb+0xc7/0x2c0
udp_rcv+0x16ce/0x2260
ip_protocol_deliver_rcu+0x197/0x2d0
ip_local_deliver+0x430/0x690
ip_rcv+0x16f/0x1f0
__netif_receive_skb_one_core+0x15e/0x1c0
__netif_receive_skb+0x1e/0x110
netif_receive_skb+0xf6/0x5c0
tun_rx_batched.isra.0+0x3ab/0x790
tun_get_user+0x17c3/0x3550
tun_chr_write_iter+0xba/0x1b0
vfs_write+0x646/0x1130
</TASK>
Kernel panic - not syncing: Fatal exception in interrupt
This runs with BH disabled, so it is a panic rather than an oops. The
same is reachable with CAP_NET_RAW in a netns where a defrag point
precedes a GSO point, and from a guest whose VMM forwards
virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by
commit 3dcbdb134f ("net: gso: Fix skb_segment splat when splitting
gso_size mangled skb having linear-headed frag_list") and by
commit 9e4b7a99a0 ("net: gso: fix panic on frag_list with mixed head
alloc types") do not cover it: page-backed heads skip them, and kmalloc
heads skip them when gso_size == skb_headlen(head), which the sender
controls.
An skb entering a frag queue is an IP fragment by definition and
cannot legitimately carry GSO state: GRO does not merge fragments and
the stack segments before it fragments, so only untrusted sources are
affected. This has been reachable since
commit f43798c276 ("tun: Allow GSO using virtio_net_hdr"), the first
path that let userspace attach GSO metadata to an IP fragment. Reset
the GSO fields of every fragment as it is queued, in
inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and
6lowpan reassembly share; then neither the head nor the frag_list
members of the reassembled skb carry them (the members matter too:
the ip_do_fragment()/ip6_fragment() fast paths send them out as they
are). The head may remain CHECKSUM_PARTIAL; that is already accepted
on receive and resolved by skb_checksum_help() in
ip_do_fragment()/ip6_fragment() on forward.
Tested on top of net.git (dc4b95b8fe), x86_64: the tap reproducer
above, two further IPv4 frag_list geometries that reach
BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6
fragment-header variant (udp6_ufo_fragment()) each panic the unpatched
kernel; with this patch all four datagrams are delivered intact and
nothing is logged.
Fixes: f43798c276 ("tun: Allow GSO using virtio_net_hdr")
Cc: stable@kernel.org
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Xinyang Ge <xinyang@anthropic.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/937926e509f2acd8e0e66520dc2b30fd6b4d1687.1787839506.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
htb_classify() follows each filter-selected inner class by switching
to cl->filter_list, but never bounds the number of hops. A filter on
an inner class can point back to itself or to another inner class that
points back, creating an infinite loop in the packet classification
path with the qdisc lock held and BH disabled — a soft lockup / panic
from a single packet.
Bound the traversal with a hop counter and drop the packet with a
rate-limited warning once the bound is exceeded. The counter is
incremented at the point the inner filter chain is picked up, after the
TC_ACT_* switch has consumed the classifier verdict, so a terminal
TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr
to __NET_XMIT_STOLEN and the packet is not charged as a drop by this
qdisc or its parent.
The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than
from the qdisc hierarchy depth limit. Class levels run from 0 to
TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can
take at most TC_HTB_MAXDEPTH hops. That descent is what a sane
configuration does, but it is assumed here rather than enforced:
htb_find() resolves a classid against every class in the qdisc, so a
filter may equally select a sibling or an ancestor. The normal
root -> inner -> leaf path takes a single hop, so the bound does not
affect legitimate classification.
htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT,
whereas previously every NULL return sat inside that ifdef. The NULL
handler in htb_enqueue() therefore cannot stay conditional either, so
drop the ifdef around it. This matches hfsc_enqueue(), which has always
handled a NULL class unconditionally. Without it, a kernel built
without actions would dereference a NULL class instead of dropping.
Conditions to recreate the bug:
- CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32,
CONFIG_LOCKUP_DETECTOR.
- Create an HTB qdisc on a device (e.g. lo), add an inner class
1:1 with a leaf child 1:10, install a root u32 filter selecting
1:1, and an inner-class u32 filter on 1:1 also selecting 1:1.
- Send one packet (ping). On the unfixed kernel the classify loop
spins with the qdisc lock held; with softlockup_panic=1 it panics.
- Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Reported-by: Vega <vega@nebusec.ai>
Co-developed-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260826143339.271935-1-victor@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Drive a connection into urgent mode and force a multi-segment retransmit,
checking that each retransmitted segment keeps its own urg_ptr.
The test asserts the fixed behaviour: the hole is retransmitted as two
independent skbs, each with its own urg_ptr (5001 and 4001) and no PSH.
An unpatched kernel instead sends one super-skb whose GSO split copies
urg_ptr onto the second segment and also sets PSH there, so on an unpatched
kernel the mismatch shows up on the PSH bit (actual P.U ... urg 5001) before
the urg_ptr:
tcp_urg_ptr_retransmit.pkt:63: live packet field tcp_psh:
expected: 0 (0x0) vs actual: 1 (0x1)
script packet: .U 1001:2001(1000) ack 1
actual packet: P.U 1001:2001(1000) ack 1 win 1050
After the fix the retransmit carries a per-segment urg_ptr and the test
passes.
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260826141145.67823-2-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
On the normal xmit path, while in urgent mode we refuse to build a
multi-segment TSO packet, so every segment gets its own urg_ptr:
/* tcp_write_xmit() */
limit = mss_now;
if (tso_segs > 1 && !tcp_urg_mode(tp))
limit = tcp_mss_split_point(...);
The retransmit path has no such guard. __tcp_retransmit_skb() builds a
segs > 1 skb and hands it to the GSO layer, which only advances th->seq
per segment and copies urg_ptr verbatim:
/* __tcp_retransmit_skb() */
len = cur_mss * segs; /* segs > 1, no urg_mode check */
...
/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */
urg_ptr is an offset from the segment's own seq, so a copied value points
at a different place on each segment. The receiver rebuilds the absolute
urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead
of the one OOB byte:
seg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok)
seg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS)
seg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS)
The real OOB byte is never pointed at, so the receiver stops splicing it
out and delivers it as normal in-band data, corrupting the stream.
Guard the retransmit length like the xmit path: keep segs = 1 while in
urgent mode.
Fixes: 10d3be5692 ("tcp-tso: do not split TSO packets at retransmit time")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260826141145.67823-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
syzbot reported a shift-out-of-bounds in __vcc_connect():
UBSAN: shift-out-of-bounds in net/atm/common.c:382:32
shift exponent -1 is negative
CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
ubsan_epilogue+0xa/0x30 lib/ubsan.c:233
__ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494
__vcc_connect+0x14b4/0x19c0 net/atm/common.c:382
vcc_connect+0x328/0x8f0 net/atm/common.c:498
pvc_bind+0x272/0x380 net/atm/pvc.c:52
__sys_bind+0x2e3/0x410 net/socket.c:1976
__x64_sys_bind+0x7a/0x90 net/socket.c:1979
...
ATM device ci_range fields (vpi_bits and vci_bits) represent the
number of bits supported for VPI and VCI addressing on the device.
net/atm/common.c directly uses these fields as bit shift counts:
vpi >> dev->ci_range.vpi_bits
vci >> dev->ci_range.vci_bits
1 << vcc->dev->ci_range.vpi_bits
1 << vcc->dev->ci_range.vci_bits
usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to
ATM_CI_MAX (-1), which is defined in <uapi/linux/atmdev.h> as a
sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit
count. Shifting by -1 is undefined behavior and triggers UBSAN
warnings.
ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits
for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as
done by solos-pci.
Fixes: c59bba75fa ("[PATCH] USB ATM: new usbatm core")
Reported-by: syzbot+6665d3db5fef15914802@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6665d3db5fef15914802
Suggested-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/all/20260824024620.23485-1-kartikey406@gmail.com/T/ [v1]
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
Link: https://patch.msgid.link/20260826133258.8306-1-kartikey406@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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: 32cba57ba7 ("net: fec: introduce fec_ptp_stop and use in probe fail path")
Reviewed-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260826103428.32807-1-phucduc.bui@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read
in slip_receive_buf() when racing against tty hangup.
tty_ldisc_hangup() calls ld->ops->hangup() while holding only
a read lock on tty->ldisc_sem (via tty_ldisc_ref()).
Because slip_hangup() simply called slip_close(), it ran concurrently
with reader functions such as slip_receive_buf().
slip_close() unregisters and frees the net device and its private
struct slip, causing concurrent reader threads in slip_receive_buf()
to dereference freed memory.
Line discipline close() is already guaranteed to be called under
the write lock of tty->ldisc_sem during hangup processing
(in tty_ldisc_reinit() or tty_ldisc_kill()).
Remove slip_hangup() so teardown is serialized cleanly by slip_close().
Fixes: 5342b77c41 ("slip: Clean up create and destroy")
Reported-by: Jaeyoung Chung <jjy600901@snu.ac.kr>
Reported-by: Eulgyu Kim <eulgyukim@snu.ac.kr>
Closes: https://lore.kernel.org/netdev/20260825150655.1450271-1-jjy600901@snu.ac.kr/
Cc: Qingfang Deng <qingfang.deng@linux.dev>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260826105238.3323436-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A couple of fixes that came in during the merge window, Geert fixed an
uninitialised data bug in the amlogic-spisg driver which could crash and
in the Loongson driver Li Jun hooked up the existing suspend operations
more fully to fix hibernation.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmqQOiIACgkQJNaLcl1U
h9Ctqgf/Z4nnPtUfZlh7ecod1NscPzlH/49BCTEK1+P17tP7c76FIKEM2ZBoJU7j
MTJ6YkUzXkAp5uEyodLPqQiC6lr6XKTNGwO3Al4Mz4toLMbHdnKrb5xZHClmkyFh
LjHcvHijZL17Gt72fa4He6UtGx0y0mZBEnbiOkQA3Z4eMgHrL3Knw8i8xmz7sqoU
K5vbgkHFgv5o75WhCQRzNakDMlssq8e8Xy2U+sxLsepJoTVbFg4RT6l0S+7iHPrk
05F/50dPbT/bd/jkFSji5ynpoLPEtBOle/vBLwbxwWzk0AOIxx2xhFVwXK6QEAMk
7zmTsceKe0wWcQW+rRKi+d6SMFPxMQ==
=IW97
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A couple of fixes that came in during the merge window: Geert fixed an
uninitialised data bug in the amlogic-spisg driver which could crash
and in the Loongson driver Li Jun hooked up the existing suspend
operations more fully to fix hibernation"
* tag 'spi-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: loongson: pm: add .freeze .poweroff .thaw .restore
spi: amlogic-spisg: Make sure clk_init_data is fully initialized
br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under
br->multicast_lock before stopping a VLAN's multicast context. That is
the teardown handshake: lockless readers gate on the flag through
br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so
once it is cleared under the lock no reader can arm the context again.
For a master VLAN the handshake never runs. __vlan_del() clears
BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so
br_multicast_toggle_one_vlan(masterv, false) returns early on
!br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is
never taken. br_vlan_put_master() then drains the context in
br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a
reader still inside rcu_read_lock() sees the context as enabled and
re-arms it. The port and port-VLAN branch of the function has no
br_vlan_is_brentry() test and flips the flag under br->multicast_lock,
so it is not affected.
The reader is the bridge transmit path. For a master VLAN
br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with
pmctx = NULL, so IGMP sent to the bridge device re-arms the context's
timers after br_multicast_ctx_deinit() has already stopped them.
BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0
Write of size 8 at addr ffff88810ac39918 by task brmc/601
__mod_timer+0x51a/0xc50
br_multicast_host_join+0x25b/0x390
__br_multicast_add_group+0x468/0x530
br_ip4_multicast_add_group+0x1a0/0x260
br_multicast_rcv+0x2cda/0x61e0
br_dev_xmit+0x6c4/0x1540
Allocated by task 610:
br_vlan_add+0x111/0xb40
br_vlan_info+0x370/0x3e0
Freed by task 0:
kfree+0x1a7/0x4f0
rcu_core+0x7dc/0x10a0
Only test br_vlan_is_brentry() when enabling, like the
br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then
always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before
br_multicast_ctx_deinit() drains the context.
Fixes: 7b54aaaf53 ("net: bridge: multicast: add vlan state initialization and control")
Cc: stable@vger.kernel.org
Signed-off-by: Norbert Szetei <norbert@doyensec.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://patch.msgid.link/D400F6C7-543A-4B79-9E5B-D1D8974DE5C9@doyensec.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
