wireguard-linux/Documentation/networking, branch stable

tcp: do not let tcp_rmem be set below 4096

2026-09-15T13:21:17Z

We can hit a division by zero crash in tcp_rcvbuf_grow() and tcp_rcv_space_adjust(): divide error: 0000 [#1] PREEMPT SMP RIP: 0010:tcp_rcvbuf_grow+0x187/0x450 net/ipv4/tcp_input.c:939 ... grow = div_u64(((u64)rcvwin << 1) * (newval - oldval), oldval); The division uses oldval = tp->rcvq_space.space as divisor. When tp->rcvq_space.space is zero, this leads to a divide-by-zero exception. tp->rcvq_space.space is initialized in tcp_init_buffer_space(): tp->rcvq_space.space = min3(tp->rcv_ssthresh, tp->rcv_wnd, (u32)TCP_INIT_CWND * tp->advmss); If tcp_rmem[1] is configured to very small values (such as 1), sk->sk_rcvbuf is initialized to 1. Then tcp_full_space(sk), which computes (sk->sk_rcvbuf * scaling_ratio) >> 8, truncates to 0. This sets tp->window_clamp = 0, tp->rcv_ssthresh = 0, and tp->rcvq_space.space = 0. Later, when data arrives and DRS is invoked, tcp_rcvbuf_grow() divides by oldval == 0. Back in 2015, commit b1cb59cf2efe ("net: sysctl_net_core: check SNDBUF and RCVBUF for min length") ensured that net.core.rmem_default and net.core.rmem_max cannot be set below SOCK_MIN_RCVBUF. Similarly, SO_RCVBUF setsockopt enforces max_t(int, val * 2, SOCK_MIN_RCVBUF). However, net.ipv4.tcp_rmem still had .extra1 = SYSCTL_ONE, allowing arbitrarily small values. Because SOCK_MIN_RCVBUF depends on sizeof(struct sk_buff) and cacheline alignment, its value varies across architectures and configuration options. Using a fixed constant of 4096 ensures a predictable, architecture- independent lower bound that is safely above SOCK_MIN_RCVBUF everywhere and matches the documented 4K default. Fix this by setting tcp_rmem.extra1 to 4096 and updating the documentation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260912144848.3448026-1-edumazet@google.com Signed-off-by: Paolo Abeni

neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS.

2026-09-12T00:25:13Z

NDTPA_INTERVAL_PROBE_TIME_MS sets .type and .min but misses .validation_type, so no validation is applied: # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 0}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 Moreover, nla_get_msecs() uses msecs_to_jiffies(), and u64 is silently cast to u32, so a larger value can bypass the min check: e.g. 4294967296 == 0x100000000 # ynl --family rt-neigh --do setneightbl \ --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 4294967296}}' # ynl --family rt-neigh --dump getneightbl --output-json | \ jq '.[] | select(.name == "arp_cache" and has("config")) | .parms["interval-probe-time-ms"]' 0 msecs_to_jiffies() returns MAX_JIFFY_OFFSET if the value is larger than INT_MAX. Also, INT_MAX ms overflows int NEIGH_VAR() when HZ > 1000 (Alpha, MIPS), and passing a negative integer to queue_delayed_work(unsigned long delay) causes sign extension, which wraps around the expiry time to the past, resulting in it being handled as 0 delay in the timer wheel. Let's use NLA_POLICY_FULL_RANGE() and limit the max to 1 day. The same max check is applied to sysctl as well. Note that this controls the probe interval for NTF_MANAGED entries, so the max of 1 day is unlikely to break any deployments. Fixes: 211da42eaa45 ("net, neigh: introduce interval_probe_time_ms for periodic probe") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260909233143.2401847-3-kuniyu@google.com Signed-off-by: Jakub Kicinski

docs: oa-tc6-framework: Fix link to specification

2026-08-20T20:31:54Z

Current link for 10BASE-T1x MAC-PHY Serial Interface Specification doesn't work - it returns 404. Update the link to the working one. Signed-off-by: Stefan Wahren Acked-by: Randy Dunlap Link: https://patch.msgid.link/20260818135958.17311-1-wahrenst@gmx.net Signed-off-by: Jakub Kicinski

Merge tag 'linux-can-next-for-7.3-20260818' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next

2026-08-18T17:30:21Z

Marc Kleine-Budde says: ==================== pull-request: can-next 2026-08-18 The first patch is by Sean Nyekjaer, targets the tcan4x5x driver and puts the device into sleep mode before removing the driver. Pavel Pisa's patch fixes the colors in the documentation of the TX buffer FSM of CTU CAN FD driver. 2 patches by Cunhao Lu add support for the rockchip 3588 SoC to the rockchip CAN-FD driver. Kuniyuki Iwashima contributes per-netns device unregistration for the vxcan driver. Eduard Bostina converts the TI HECC DT bindings doc to DT schema. Harini T contributes 2 patches to the xilinx_can driver to document phys and update maintainer. A patch by bui duc phuc converts the m_can driver to use of_property_present() for wakeup-source. Fanbo He's patch fixes a typo in the gs_usb driver. The last patch is by Markus Schneider-Pargmann and removed not needed driver_data from the m_can PCI driver. * tag 'linux-can-next-for-7.3-20260818' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: m_can: pci: Remove driver_data drivers: gs_usb: gs_usb_probe(): fix typo in error message can: m_can: Use of_property_present() for wakeup-source dt-bindings: can: xilinx_can: Document phys property dt-bindings: net: can: Convert TI HECC to DT schema MAINTAINERS: Replace maintainer for Xilinx CAN driver can: vxcan: support per-netns device unregistration. docs: ctucanfd: fix swapped colors in legend for TX buffer FSM of CTU CAN FD can: rockchip: add RK3588 CAN support dt-bindings: can: rockchip: add rk3588 CAN-FD compatible can: tcan4x5x: put tcan into sleep when removing driver ==================== Link: https://patch.msgid.link/20260817233420.2068204-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski

docs: ctucanfd: fix swapped colors in legend for TX buffer FSM of CTU CAN FD

2026-08-17T17:20:37Z

The Inaccessible and Accessible legend colors has been swapped for many years. As I have helped to clean the CTU CAN FD section of official documentation for mass produced silicon (multiple models of microcontrollers) with the company representatives, I have found the problem and propagate correction bask to the primary CTU CAN FD sources. Signed-off-by: Pavel Pisa Link: https://patch.msgid.link/d775feefa1c16d7ea7f42482483c81491f75ce6c.1785574572.git.pisa@cmp.felk.cvut.cz Signed-off-by: Marc Kleine-Budde

ixd: add devlink support

2026-08-12T20:56:51Z

Enable initial support for the devlink interface with the ixd driver. The ixd hardware is a single function PCIe device. So, the PCIe adapter gets its own devlink instance to manage device-wide resources or configuration. $ devlink dev show pci/0000:83:00.6 $ devlink dev info pci/0000:83:00.6 pci/0000:83:00.6: driver ixd serial_number 00-a0-c9-ff-ff-23-45-67 versions: fixed: device.type MEV running: fw.mgmt.api 2.0 Signed-off-by: Amritha Nambiar Reviewed-by: Michal Swiatkowski Reviewed-by: Maciej Fijalkowski Reviewed-by: Przemek Kitszel Tested-by: Bharath R Signed-off-by: Larysa Zaremba Signed-off-by: Tony Nguyen

ixd: add basic driver framework for Intel(R) Control Plane Function

2026-08-12T20:56:51Z

Add module register and probe functionality. Add the required support to register IXD PCI driver, as well as probe, remove and shutdown callbacks. Enable the PCI device and request to reserve the memory resources that will be used by the driver. Finally map the BAR0 address space. For now, use devm_kzalloc() to allocate adapter, as it requires the least amount of code. In a later commit, it will be replaced with a devlink alternative. Co-developed-by: Amritha Nambiar Signed-off-by: Amritha Nambiar Reviewed-by: Maciej Fijalkowski Tested-by: Bharath R Signed-off-by: Larysa Zaremba Signed-off-by: Tony Nguyen

net/mlx5: implement max_sfs parameter

2026-08-12T01:06:30Z

Implement max_sfs generic parameter to allow users to control the total light-weight NIC subfunctions that can be created using devlink instead of external vendor tools. A value of 0 will effectively disable creation of new subfunction devices. A warning is sent to user-space via extack (returning extack without error code is interpreted as a warning by user-space tools). The maximum value is capped at U16_MAX. Signed-off-by: Nikolay Aleksandrov Reviewed-by: David Ahern Reviewed-by: Alexander Lobakin Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260806073037.3001886-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski

devlink: add generic device max_sfs parameter

2026-08-12T01:06:30Z

Add a new generic devlink device parameter (max_sfs) to control if and how many light-weight NIC subfunctions can be created. Subfunctions are a light-weight network functions backed by an underlying PCI function. Their lifecycle can already be managed by devlink, but currently users cannot enable them in the device. They can be enabled/disabled only via external vendor tools. This parameter allows subfunctions to be enabled (>0) or disabled (0) via devlink. A subsequent patch will add support for max_sfs to the mlx5 driver. Signed-off-by: Nikolay Aleksandrov Reviewed-by: David Ahern Reviewed-by: Jiri Pirko Reviewed-by: Aleksandr Loktionov Reviewed-by: Alexander Lobakin Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260806073037.3001886-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski

tun/tap & vhost-net: stop tail-drop when IFF_BACKPRESSURE is set

2026-08-08T00:29:16Z

This commit prevents tail-drop when IFF_BACKPRESSURE is set, a qdisc is present and the ptr_ring becomes full. Once the ring reaches capacity after a produce attempt, the netdev queue is stopped instead of dropping subsequent packets. Without the flag, or if no qdisc is present, the previous tail-drop behavior is preserved. IFF_BACKPRESSURE is added to TUN_FEATURES here and not in the patch that defines it, so that TUNSETIFF honours the flag only once the implementation behind it is complete. The unconditional version of this behavior was reverted because it caused a significant throughput drop in an IPv6 multicast testcase on Brett Sheffield's librecast testbed [1]: with 8 iperf3 TCP threads sending, the throughput dropped from 13.5 Gbit/s to 9.13 Gbit/s. This is why the queue stopping is now gated on IFF_BACKPRESSURE. If producing an entry fails anyway due to a race, tun_net_xmit() drops the packet. Such rare races are expected because LLTX is enabled and the transmit path operates without the usual locking. The queue state is only touched while the device is running. The stop itself would be harmless during teardown, as tun_net_close() sets the same bit, but the re-check below it wakes the queue again and must not clear that stop. A later TUNSETIFF can clear the flag again while the device has at most one queue. Past that point tun_set_iff() returns before it writes tun->flags, which is how it already treats every other TUN_FEATURES bit. For the case where the flag does change, tun_set_iff() calls tun_force_wake_queue() for the attached tfiles, so that no queue stays stopped without a consumer that would wake it. The __tun_wake_queue() function of the consumer races with the producer for waking/stopping the netdev queue, which could result in a stalled queue. Therefore, an smp_mb__after_atomic() is introduced that pairs with the smp_mb() of the consumer. It follows the principle of store buffering described in tools/memory-model/Documentation/recipes.txt: - The producer in tun_net_xmit() first sets __QUEUE_STATE_DRV_XOFF, followed by an smp_mb__after_atomic() (= smp_mb()), and then reads the ring with __ptr_ring_check_produce(). - The consumer in __tun_wake_queue() first writes zero to the ring in __ptr_ring_consume(), followed by an smp_mb(), and then reads the queue status with netif_tx_queue_stopped(). => Following the aforementioned principle, it is impossible for the producer to see a full ring (and therefore not wake the queue on the re-check) while the consumer simultaneously fails to see a stopped queue (and therefore also does not wake it). tun_net_xmit() holds only the producer_lock and can not reset cons_cnt, which the consumer_lock protects, so the wake on the re-check leaves stale credit behind. That is accepted as best-effort, the re-check rarely succeeds and the next drain corrects the count. The documentation in tuntap.rst is updated accordingly. Benchmarks: My own benchmarks show a slight regression in raw transmission performance when using two sending threads. Packet loss also occurs only in the two-thread sending case; no packet loss was observed with a single sending thread. Test setup: AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads; Average over 50 runs @ 100,000,000 packets. SRSO and spectre v2 mitigations disabled. Note for tap+vhost-net: XDP drop program active in VM -> ~2.5x faster; slower for tap due to more syscalls (high utilization of entry_SYSRETQ_unsafe_stack in perf) +--------------------------+--------------+----------------+----------+ | 1 thread | Stock | Patched with | diff | | sending | | fq_codel qdisc | | +------------+-------------+--------------+----------------+----------+ | TAP | Received | 1.132 Mpps | 1.123 Mpps | -0.8% | | +-------------+--------------+----------------+----------+ | | Lost/s | 3.765 Mpps | 0 pps | | +------------+-------------+--------------+----------------+----------+ | TAP | Received | 3.857 Mpps | 3.901 Mpps | +1.1% | | +-------------+--------------+----------------+----------+ | +vhost-net | Lost/s | 0.802 Mpps | 0 pps | | +------------+-------------+--------------+----------------+----------+ +--------------------------+--------------+----------------+----------+ | 2 threads | Stock | Patched with | diff | | sending | | fq_codel qdisc | | +------------+-------------+--------------+----------------+----------+ | TAP | Received | 1.115 Mpps | 1.081 Mpps | -3.0% | | +-------------+--------------+----------------+----------+ | | Lost/s | 8.490 Mpps | 391 pps | | +------------+-------------+--------------+----------------+----------+ | TAP | Received | 3.664 Mpps | 3.555 Mpps | -3.0% | | +-------------+--------------+----------------+----------+ | +vhost-net | Lost/s | 5.330 Mpps | 938 pps | | +------------+-------------+--------------+----------------+----------+ [1] https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/ Co-developed-by: Tim Gebauer Signed-off-by: Tim Gebauer Signed-off-by: Simon Schippers Link: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/ Link: https://patch.msgid.link/20260803183641.96882-6-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski