summaryrefslogtreecommitdiff
path: root/net
AgeCommit message (Collapse)Author
2026-08-15bpf: Add ksock kfuncsMahe Tardy
Add BPF kfuncs that allow BPF LSM programs to create and use sockets for sending data. This provides a mechanism for BPF programs to emit telemetry. For this first patch set, it's restricted to SOCK_DGRAM socket types with IPPROTO_UDP protocol but could be easily extended to SOCK_STREAM and IPPROTO_TCP in the future. The API consists of five kfuncs: bpf_ksock_create() - Create a socket (sleepable) bpf_ksock_connect() - Connect socket to remote address (sleepable) bpf_ksock_send() - Send data through the socket (sleepable) bpf_ksock_acquire() - Acquire a reference to a socket context bpf_ksock_release() - Release a reference (cleanup via queue_rcu_work since sock_release sleeps) The setup kfuncs bpf_ksock_create, bpf_ksock_connect, can be called from SYSCALL programs only. While bpf_ksock_acquire, bpf_ksock_release and bpf_ksock_send can be called from SYSCALL and LSM programs. The implementation follows the established kfunc lifecycle pattern (create/acquire/release with refcounting, kptr map storage, dtor registration). The kernel socket is wrapped in a refcounted bpf_ksock struct. Cleanup is deferred via queue_rcu_work() because sock_release() may sleep. The kfuncs are only compiled when CONFIG_INET is enabled, as they specifically support AF_INET and AF_INET6 sockets. The socket operations go through the expected LSM hooks instead of by-passing them like many kernel sockets since those are created by BPF programs and thus system users. Thus, the bpf_ksock_send() kfunc, which is exposed to LSM progs has a verifier filter protection to avoid recursion so that the whole bpf_kfunc_set kfunc set cannot be called in a program attached to security_socket_sendmsg(). Also, because of the LSM checks, we prevent the use of the kfuncs from asynchronous workqueue as the current value would then be invalid. In bpf_ksock_create(), we copy the arg values to avoid TOCTOU races since the kfunc can sleep and the arg values could be stored in a map that could be re-written by BPF progs or even userspace programs if the map is mmaped. Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/bpf/20260813110540.103550-3-mahe.tardy@gmail.com
2026-08-15net: Add connect_socket() helperMahe Tardy
Add a helper that connects an existing socket while invoking the LSM hook. Reuse it in __sys_connect_file() to avoid duplicating the connect logic. Other socket operations have equivalent helpers that trigger the appropriate LSM hooks that can be reused, this one was the only one missing. This will be used in the next commit for a new BPF kfunc that needs to connect a socket and trigger the LSM hook. Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Acked-by: Song Liu <song@kernel.org> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://lore.kernel.org/bpf/20260813110540.103550-2-mahe.tardy@gmail.com
2026-08-14net: dsa: drop explicit NULL comparisonsKai Kuang
Replace explicit NULL comparisons with the boolean form to follow the kernel coding style: dev->class != NULL -> dev->class user_dev == NULL -> !user_dev No functional changes intended. Signed-off-by: Kai Kuang <kuangkai@kylinos.cn> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260812060644.210997-1-kuangkai@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-14gre: fix ERSPAN o_flags race/corruption in xmit and fill_infoEric Dumazet
For IPv4 ERSPAN: In erspan_xmit(), the driver clears IP_TUNNEL_SEQ_BIT (for version 0) and IP_TUNNEL_KEY_BIT directly in the shared tunnel->parms.o_flags structure. Since transmit paths can run locklessly and concurrently, this leads to a data race. Furthermore, modifying tunnel->parms.o_flags permanently alters the tunnel configuration. To work around this, erspan_fill_info() (which reports config to userspace) was setting IP_TUNNEL_KEY_BIT back. If erspan_fill_info (running under RTNL) and erspan_xmit (running locklessly) race, erspan_xmit might see IP_TUNNEL_KEY_BIT set when it shouldn't, leading to GRE header corruption (injecting a key field into the ERSPAN GRE header). Fix this by: 1) Passing flags as an argument to __gre_xmit(). 2) Using local stack flags in ipgre_xmit(), gre_tap_xmit(), and erspan_xmit() to prevent TOCTOU data races with concurrent configuration updates, and passing them to __gre_xmit(). 3) Removing the racy modification of t->parms.o_flags in erspan_fill_info(). 4) Forcing IP_TUNNEL_KEY_BIT in the reported flags for ERSPAN locally in ipgre_fill_info(). For IPv6 ERSPAN: ip6erspan_tunnel_xmit() was locklessly clearing IP_TUNNEL_KEY_BIT in t->parms.o_flags even though it does not use these flags for building the GRE header (it uses local flags). This permanently corrupts the configuration and races with ip6gre_fill_info() which reads it. Remove the redundant and racy modification. This should remove false sharing in a fast path. Add const qualifiers in ipgre_fill_info(), erspan_fill_info() and ip6gre_fill_info() to clarify that these methods are not supposed to write any live parameters. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260812142257.21283-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-14Merge tag 'nf-next-26-08-10' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next Pablo Neira Ayuso says: ==================== Netfilter updates for net This includes an enhancement to detect ct memleaks easier via DEBUG_NET and flowtable preparation patches for IPv4 over IPV6 and vice-versa. This also includes a fix for the nft_ct custom expectation support. 1) Add DEBUG_NET_WARN_ON_ONCE to nf_ct_set() to spot ct memleaks. 2) Pass struct net_device_path_ctx to dev_fill_forward_path() to make it easier to pass more parameters to this function. From Lorenzo Bianconi. 3) Add ether_type field to net_device_path context structucture. 4) Rename tun.l3_proto field to tun.inner_proto. 5) Rename ctx.tun.proto to ctx.tun.inner_proto. 6) Store ether_type in flowtable context. 7) Move IPv4 and IPv6 xmit path to a helper function. 8) Move encapsulation header parser out of the flowtable lookup function. 9) Rework nft_ct custom expectation support to address a possible reallocation of ct extension area while expectation list also contains expectations. Move datapath to a ct helper to fix it. 10) Ensure timeout is always lowered for the non-closing RST case in the TCP connection tracking. 11) Bail out when inserting already dead expectation, this should not ever happen, hence report it via DEBUG_NET. 12) Comestic updates for improving the conntrack selftest dump and flush userspace program, from Qingshuang Fu. * tag 'nf-next-26-08-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next: selftests: netfilter: conntrack_dump_flush: remove unused variables and fix typo netfilter: nf_conntrack_expect: bail out on insert dead expectations netfilter: conntrack: always lower timeout for non-closing RST packets netfilter: nft_ct: move custom expectation support to helper netfilter: flowtable: detach layer 2 encapsulation parser from lookup netfilter: flowtable: move ipv4 and ipv6 xmit path to function netfilter: flowtable: store ethertype in flowtable context netfilter: flowtable: rename ctx.tun.proto to ctx.tun.inner_proto netfilter: flowtable: rename tun.l3_proto to tun.inner_proto net: netfilter: add ether_type to net_device_path_ctx and use it net: pass net_device_path_ctx to dev_fill_forward_path() netfilter: add DEBUG_NET_WARN_ON_ONCE to skb_set_nfct() ==================== Link: https://patch.msgid.link/20260810194015.932627-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-14Merge tag 'ceph-for-7.2-rc8' of https://github.com/ceph/ceph-clientLinus Torvalds
Pull ceph fixes from Ilya Dryomov: "A handful of tiny fixes, with the main ones being a follow-up for CEPH_IOC_SET_LAYOUT{,_POLICY} ioctl permissions check that went into rc5 and a userspace compatibility fixup. The rest mostly harden against malformed network input. All marked for stable" * tag 'ceph-for-7.2-rc8' of https://github.com/ceph/ceph-client: ceph: use the mount idmap for the owner checks in the SET_LAYOUT ioctls ceph: fix MDS random selection readiness predicate libceph: Avoid using invalid osd indices from primary_temp libceph: fix OOB read in decode_watchers() via missing bounds check libceph: fix multiple unsafe decodes in decode_locker() libceph: tolerate addrvecs with multiple entries of the same type
2026-08-13net: page_pool: fix UAF in __page_pool_release_netmem_dma on xa_cmpxchg raceJijie Shao
This bug was discovered while testing the hns3 driver under channel reconfiguration (`ethtool -L` / `ethtool -G`) with iperf3 traffic on arm64. The race is intermittently triggered when page_pool_destroy() runs page_pool_scrub() concurrently with page return via page_pool_put_netmem() on a different CPU. A WARN in page_pool_clear_pp_info() surfaced the dangling DMA index bits left by the cmpxchg loser, which led to the investigation. page_pool_scrub() iterates pool->dma_mapped via xa_for_each() with no page ref held. __page_pool_release_netmem_dma() currently reads and writes netmem fields (dma_addr, DMA index bits in pp_magic) after xa_cmpxchg() returns. The unref path calls put_page() unconditionally regardless of the cmpxchg outcome; when it loses the cmpxchg, it still frees the page before the scrub winner finishes these netmem accesses, so scrub touches a freed page -- a Use-After-Free. Fix this by splitting the DMA release into two functions: 1. __page_pool_unmap_netmem_dma() caches dma_addr before xa_cmpxchg(), does the cmpxchg to remove the DMA mapping, and calls dma_unmap on the cached address. It never touches netmem fields after the cmpxchg, making it safe for the scrub path which holds no page ref. 2. __page_pool_release_netmem_dma() wraps the above and additionally clears dma_addr and DMA index bits in netmem fields. This is safe only when the caller holds a page ref, so it is used by the return path (page_pool_return_netmem). The scrub path calls __page_pool_unmap_netmem_dma() directly; the return path calls __page_pool_release_netmem_dma(). Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Suggested-by: Mina Almasry <almasrymina@google.com> Reviewed-by: Mina Almasry <almasrymina@google.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://patch.msgid.link/20260807114830.344336-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-13net: openvswitch: unexport ovs_vport_alloc/freeIlya Maximets
Since removal of the legacy tunnel port types, there are no more users for these functions outside the main openvswitch module. Functions to register vport_ops are also not exported. Allocating vports without operations doesn't make a lot of sense. Highlighted by Sashiko as a follow up to the removal of the module infrastructure. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Aaron Conole <aconole@redhat.com> Link: https://patch.msgid.link/20260812122007.457136-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-13ethtool: tsconfig: reject zero-valued tx_type and rx_filter bitsetsJakub Kicinski
The ffs()/fls() guard in ethnl_set_tsconfig() was meant to enforce that the user selects exactly one tx_type (and one rx_filter) at a time (off / none are explicit types with non-zero values). However, both ffs(0) and fls(0) return 0, so the guard passes a zero-valued bitset through. The subsequent ffs(req_tx_type) - 1 would produce -1, if user selected no bit. net_hwtstamp_validate() catches the invalid -1 downstream, but returns a generic error (-ERANGE) without telling the user what went wrong. Return -EINVAL + extack instead. Replace the ffs()/fls() comparison with a hweight32() == 1 check. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Joe Damato <joe@dama.to> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260812162230.1837788-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-13l2tp: send netlink notifications in the tunnel's net namespaceMaoyi Xie
l2tp_tunnel_notify() and l2tp_session_notify() use genlmsg_multicast_allns(), which delivers to listeners in every network namespace. l2tp is per-namespace, and a tunnel records the namespace it belongs to in tunnel->l2tp_net. Each event concerns one namespace, yet every namespace is told about it. A tunnel event carries the tunnel and peer tunnel ids, plus the socket's addresses with both ports for a UDP tunnel. A session event carries the session and peer session ids, the interface name, plus the L2TP cookies where those are set. A listener needs no privilege for any of this, because l2tp_multicast_group[] carries no flags and genl_bind() asks for no capability. The fix is to send to the tunnel's namespace with genlmsg_multicast_netns(). Commit 134e63756d5f ("genetlink: make netns aware") added both helpers and drew the line between them. The netns variant is for an object that lives in a namespace. I found this by auditing the tree's six genlmsg_multicast_allns() call sites for objects that live in a network namespace. Only the two l2tp ones do. I reproduced it on net at dd057113ac7b, in a virtual machine, with no real hardware involved. A process in the initial namespace, running as an ordinary user with an empty capability set, receives the create and delete events of a tunnel. The tunnel was set up inside an unprivileged user and network namespace. tools/testing/selftests/net/l2tp.sh passes before and after. On a container host, any local user and every other tenant can read a tenant's tunnel parameters. Cc: stable+noautosel@kernel.org # high regression risk Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260809094252.2107242-1-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-13net/smc: do not dereference an unset send buffer on the SMC-D teardown pathBryam Vargas
smc_close_stream_wait() calls smc_tx_prepared_sends() from inside its sk_wait_event() condition, and sk_wait_event() evaluates that condition once with the socket lock released. smcd_buf_detach() clears conn->sndbuf_desc from smc_conn_kill() under lock_sock(), so a link group terminating while a socket waits there leaves the helper dereferencing NULL, faulting out of close(). SIOCOUTQ reads the field by hand, and smc_close_cancel_work() drops the lock across two cancel_*_sync() calls. Sample the pointer once in the helper, report nothing prepared while it is unset, and bound the ioctl the same way. The receive tasklet dereferences the field directly in smc_cdc_msg_recv_action(), not through this helper; 1/2 is what keeps it from running that late. Fixes: ae2be35cbed2 ("net/smc: {at|de}tach sndbuf to peer DMB if supported") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Link: https://patch.msgid.link/20260808-b4-disp-22f119e6-v2-2-61647601a6f3@proton.me Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-13net/smc: unregister the connection before draining the rx taskletBryam Vargas
smc_conn_free() calls smc_ism_unset_conn() only while the link group is still on its device list, and never sets conn->killed. smc_lgr_terminate_sched() unlinks the group immediately and defers killing its connections to a work item, so a connection freed in that window keeps its smcd->conn[] slot with both gates in smcd_handle_irq() open, and the device can re-arm the receive tasklet after tasklet_kill() has returned. On the DMB-nocopy path the ghost send buffer is freed right after that drain, so the re-armed tasklet dereferences it. Unregister unconditionally and drain before the detach at both teardown sites, mirroring rmb_desc, which smc_buf_unuse() releases after the drain. Clear conn->sndbuf_desc before freeing it as well, so a reader that samples the pointer cannot get one that is already freed. Fixes: ae2be35cbed2 ("net/smc: {at|de}tach sndbuf to peer DMB if supported") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Link: https://patch.msgid.link/20260808-b4-disp-22f119e6-v2-1-61647601a6f3@proton.me Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.2-rc8). No conflicts. Adjacent changes: drivers/net/ethernet/wangxun/ngbe/ngbe_main.c 5f3a13e0bb5e ("net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling") d661abdc30c2 ("net: ngbe: correct misleading interrupt comment") drivers/net/ipvlan/ipvlan_main.c e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") 00a40d809207 ("ipvlan: Support per-netns netdev unregistration.") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-13Merge tag 'net-7.2-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from netfilter. There is a known WiFi/mt76 regression, waiting for a complete fix that should land soonish. Previous releases - regressions: - tcp: fix icsk_ack.ato bitfield overflow - af_unix: Unlink scc_entry in unix_del_edge() - ipv4: fix use-after-free in fib_nhc_update_mtu() - netfilter: - ipset: fix refcount race between list:set GC and swap - nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path - sched: act_ct: fix sk_buff leak when the header checks reject a packet - sctp: clear new_transport when removing a peer - dibs: correct freeing of dmb_clientid_arr - ovpn: fix NULL dereference when killing missing key - eth: - veth: fix queue index used to wake the peer txq in veth_poll - ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling - gve: fix zero-length skb frag with header-split Previous releases - always broken: - core: fix skb length accounting after generic XDP frag adjustment - af_packet: don't send zero-byte data in tpacket_snd(). - eth: - bnxt: avoid deadlock when canceling IRQ affinity notifier - ipvlan: inherit needed_headroom and needed_tailroom from phy_dev" * tag 'net-7.2-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (55 commits) l2tp: fix tunnel and session refcount leak on seq_file release net/sched: cls_bpf: reject dev-bound programs bound to a different device sctp: fix use-after-free of cached ASCONF chunk net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG sctp: clear new_transport when removing a peer net/dibs: Correct freeing of dmb_clientid_arr net/sched: cls_u32: skip hash tables in u32_bind_class() gve: fix NULL dereference due to missing ptp adjfine gve: fix zero-length skb frag with header-split net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain af_packet: Don't send zero-byte data in tpacket_snd(). tipc: read le->link under the node lock in tipc_node_link_down() selftests: tls: cover splice after a failed decrypt net/tls: Fail tls_sw_splice_read() after a failed async decrypt net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling net: tap: fix wrong transport_header when sending VLAN-tagged frame net: packet: fix wrong transport_header when sending VLAN-tagged frame vxlan: do not arm the ageing timer on a device that is down ipv4: fix use-after-free in fib_nhc_update_mtu() NTB: ntb_netdev: Preserve RX queue depth on allocation failure ...
2026-08-13net: Const qualify network templated ctl_tables ArraysJoel Granados
Add duplication helpers in the cases where the ctl_table array elements are modified after duplication. Helpers return a ctl_table as const pointer allowing the const qualification of the static global ctl_table array. Signed-off-by: Joel Granados <joel.granados@kernel.org> Link: https://patch.msgid.link/20260810-jag-net_const_qualify-v4-3-77e888237c69@kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13net: Const qualify ctl_tables that kmemdup unconditionallyJoel Granados
Const qualify clt_table arrays in the net directory that always pass a memory duplicate to sysctl register. The template would then be in .rodata and the kmemdup'ed array would be outside. Signed-off-by: Joel Granados <joel.granados@kernel.org> Link: https://patch.msgid.link/20260810-jag-net_const_qualify-v4-2-77e888237c69@kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13net: enforce net sysctl registrationJoel Granados
Replace the warning and file permission change with an error when an "unsafe" net sysctl registration is detected. One of the barriers preventing the const qualification of the ctl_tables in the net directory is the permission (->mode) change in ensure_safe_net_sysctl. This prep commit removes that barrier and ensures that the received ctl_table pointer to the net ctl_table register function is const. Signed-off-by: Joel Granados <joel.granados@kernel.org> Link: https://patch.msgid.link/20260810-jag-net_const_qualify-v4-1-77e888237c69@kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13net/rds: clear i_rx_lat_trace in rds_inc_path_init()Allison Henderson
The commit that introduced the receive-path latency trace added the clearing of inc->i_rx_lat_trace[] to rds_inc_init() only; rds_inc_path_init() never got it. That asymmetry matters for the one caller that reuses memory: rds_tcp_data_recv() carves its rds_tcp_incoming out of a kmem_cache with no zeroing and no constructor, so after rds_inc_path_init() the array still holds the timestamps of whatever message previously occupied that slab object. No stale value is user-visible today - every message that reaches the socket happens to overwrite all four slots (RX_HDR at allocation, RX_START when the header completes, RX_END at delivery, RX_CMSG at recvmsg time) before RDS_CMSG_RXPATH_LATENCY reads them back as deltas - but that is a property of the current writers, not of the init contract, and a future trace point or an early-exit path would expose another message's timestamps to userspace. Clear the array in rds_inc_path_init() too, so both init helpers leave the inc fully initialized. memset is the form the clearing already takes on the rds_inc_init() side since commit 1635bb548f84 ("net: rds: use memset to optimize the recv"). Hardening only; no user-visible bug in the current code. Assisted-by: Claude-Code:claude-fable-5 Signed-off-by: Allison Henderson <achender@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260810055631.299558-1-achender@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13net/rds: initialize i_conn_path in rds_inc_init()William Kucharski
rds_inc_init() initializes every field of the embedded rds_incoming except i_conn_path, and incomings are not zero-allocated (IB carves them out of a slab cache). The field therefore holds stale garbage for incs created by rds_ib. The loopback transport is different: rds_loop_xmit() re-runs rds_inc_init() on the message's embedded inc after rds_send_queue_rm() has already stored the connection path in it, so there the field holds a live value rather than garbage, and a NULL store would discard it. Switch rds_loop_xmit() to rds_inc_path_init() with the connection's single path, which is exactly the value readers of the field reconstruct for a non-multipath transport. With loopback preserving the field, initialize it to NULL in rds_inc_init() so that any future reader trips over a clean NULL pointer instead of a stale one, and so the two init helpers (rds_inc_init/rds_inc_path_init) leave the structure in an equivalent, fully-initialized state. Hardening only; no reader dereferences i_conn_path for a non-multipath transport today. This mirrors Oracle UEK commit "rds: rds_inc_init() should initialize the inc->i_conn_path field". Signed-off-by: William Kucharski <william.kucharski@oracle.com> [achender: port to net-next; keep loopback's i_conn_path valid by switching rds_loop_xmit() to rds_inc_path_init(); update commit message] Assisted-by: Claude-Code:claude-fable-5 Signed-off-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260809005103.82371-3-achender@kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13net/rds: reinitialize to_be_dropped on rds_send_xmit() restartSharath Srinivasan
The to_be_dropped list is declared once at the top of rds_send_xmit() but the function can loop via "goto restart" after each batch. The code currently relies on rds_send_remove_from_sock() having emptied the list entry by entry (via list_del_init()) at the end of the previous batch; nothing in rds_send_xmit() itself guarantees the list head is empty when a new batch starts. Re-initialize the list on every restart, and warn once if it is ever found non-empty there: entries left on the list at that point would keep their message reference, their RDS_MSG_ON_SOCK accounting and their pending RDS_RDMA_DROPPED notification, so a silent re-init would orphan them. This is hardening: no user-visible bug is known in the current code. This mirrors Oracle UEK commit "net/rds: rds_send_xmit should INIT_LIST_HEAD(&to_be_dropped) on restart". Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com> Signed-off-by: Sharath Srinivasan <sharath.srinivasan@oracle.com> [achender: port to net-next (keep the existing LIST_HEAD declaration and add only the restart re-init); warn if the restart invariant is violated; update commit message] Assisted-by: Claude-Code:claude-fable-5 Signed-off-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260809005103.82371-2-achender@kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13ipv6: add inet6_rt_del_notify()Yuyang Huang
Move the body of inet6_rt_notify() to __inet6_rt_notify() and give it the deletion reason. inet6_rt_notify() keeps its prototype, so the route addition path does not change. Add inet6_rt_del_notify() and call it from fib6_del_route(). RTA_DEL_REASON now reaches user space on RTM_DELROUTE for routes the kernel deleted on its own. Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260808005642.26901-7-sigefriedhyy@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13ipv6: expose the route deletion reason in RTM_DELROUTEYuyang Huang
Emit RTA_DEL_REASON from rt6_fill_node() when the deletion reason is not RT_DEL_REASON_UNSPEC, and reserve room for it in rt6_nlmsg_size(). Every caller still passes RT_DEL_REASON_UNSPEC. Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260808005642.26901-6-sigefriedhyy@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13ipv6: add a deletion reason argument to rt6_fill_node()Yuyang Huang
Add the deletion reason to rt6_fill_node() so that it can report it to user space. All callers pass RT_DEL_REASON_UNSPEC for now. Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260808005642.26901-5-sigefriedhyy@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13ipv6: record the reason for kernel-initiated route deletionsYuyang Huang
Record why the kernel deletes an IPv6 route on its own: - RT_DEL_REASON_EXPIRED for routes reaped by the FIB6 garbage collector after their RTF_EXPIRES lifetime ran out. - RT_DEL_REASON_RA_WITHDRAWN for default routes, prefix routes and RFC 4191 route information routes withdrawn by a zero-lifetime Router Advertisement. Deleting a default route because its metric changed is not a withdrawal, so it keeps RT_DEL_REASON_UNSPEC. Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260808005642.26901-4-sigefriedhyy@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13ipv6: propagate the route deletion reason to fib6_del_route()Yuyang Huang
Pass the deletion reason from ip6_del_rt_reason() down through __ip6_del_rt(), fib6_del() and into fib6_del_route(). All existing callers pass RT_DEL_REASON_UNSPEC. fib6_del_route() ignores the reason until the notification path learns to report it. Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260808005642.26901-3-sigefriedhyy@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13ipv6: add ip6_del_rt_reason()Yuyang Huang
Add RTA_DEL_REASON and enum rt_del_reason to the rtnetlink uAPI, and add ip6_del_rt_reason(), which takes the reason a route is being deleted. It has no skip_notify argument: a caller that records a deletion reason wants the notification that carries it. The reason is unused for now. Subsequent patches propagate it to the deletion path and report it on RTM_DELROUTE. Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260808005642.26901-2-sigefriedhyy@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13l2tp: fix tunnel and session refcount leak on seq_file releaseEric Dumazet
In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state (pd->tunnel and pd->session) is kept in seq_file private data to allow iteration across multiple read() system calls. However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels before reading to end-of-file (EOF), any tunnel or session reference stored in pd->tunnel / pd->session is left un-dropped when seq_file private data is freed. Fix this by dropping any remaining pd->tunnel and pd->session references in pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file. Fixes: 0e0c3fee3a59 ("l2tp: hold reference on tunnels printed in pppol2tp proc file") Fixes: f726214d9b23 ("l2tp: hold reference on tunnels printed in l2tp/tunnels debugfs file") Reported-by: syzbot+d6fa74e3f19d6ee01e3a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a760f32.01d0871a.3a0d52.004f.GAE@google.com/T/#u Assisted-by: Jetski:Gemini-3.1-Pro Cc: James Chapman <jchapman@katalix.com> Cc: Guillaume Nault <gnault@redhat.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260811144651.2733424-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-13net/sched: cls_bpf: reject dev-bound programs bound to a different deviceJamal Hadi Salim
cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device. Fixes: 2b3486bc2d23 ("bpf: Introduce device-bound XDP programs") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira <victor@mojatatu.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://patch.msgid.link/20260809094418.901607-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-08-12Merge tag 'batadv-next-pullrequest-20260805' of https://git.open-mesh.org/batadvJakub Kicinski
Simon Wunderlich says: ==================== This cleanup patchset includes the following patches: - dat: drop non-4addr backwards compatibility, by Sven Eckelmann - tvlv: handle negative tvlv processing return codes, by Sven Eckelmann - improve kernel-doc, add comments and warnings, by Sven Eckelmann (3 patches) - coding style: split declarations, reverse x-mas tree, by Sven Eckelmann (2 patches) - handle errors in batadv_init(), by Minhong He - correct NET_RX_* NET_XMIT_* confusion, by Sven Eckelmann - remove negative returns for batadv_send_skb_unicast, by Sven Eckelmann * tag 'batadv-next-pullrequest-20260805' of https://git.open-mesh.org/batadv: batman-adv: remove negative returns for batadv_send_skb_unicast batman-adv: correct NET_RX_* NET_XMIT_* confusion batman-adv: handle errors in batadv_init() batman-adv: switch var declarations to reverse x-mas tree order batman-adv: split multiple declarations per line batman-adv: annotate functions which may reallocate the skbuff batman-adv: fix kernel-doc for functions holding skb ownership batman-adv: add missing kernel-doc comments batman-adv: tvlv: handle negative tvlv processing return codes batman-adv: dat: drop non-4addr backwards compatibility ==================== Link: https://patch.msgid.link/20260805143200.722098-1-sw@simonwunderlich.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-12mac80211: fils_aead: Use __cleanup() instead of memzero_explicit()Thomas Huth
By using __cleanup(aes_cmac_zeroize_key) for clearing the key data, we can save one line of code here. Signed-off-by: Thomas Huth <thuth@redhat.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Link: https://patch.msgid.link/20260807125845.1477067-7-thuth@redhat.com Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-08-12Bluetooth: SMP: clear the aes_cmac_key when doneThomas Huth
Clear the local aes_cmac_key structure via __cleanup() function when we're done with it to avoid that sensitive data could leak on the stack. While we're at it, also clear the tmp[] array here that is populated with a raw version of the original key and thus would leak the same information via the stack otherwise. Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260807125845.1477067-5-thuth@redhat.com Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-08-12sctp: fix use-after-free of cached ASCONF chunkYuxiang Yang
addip_last_asconf caches the outstanding outbound ASCONF chunk. The normal ASCONF-ACK completion path releases the chunk and clears the pointer. However, sctp_asconf_queue_teardown() releases the cached chunk without clearing addip_last_asconf. During peer restart handling, sctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes sctp_asconf_queue_teardown() while the association remains alive and leaves the pointer dangling. A delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(), which accesses the stale chunk and passes it to sctp_process_asconf_ack(), causing a use-after-free and a second release. Clearing the pointer exposes a race with T4 expiry. Peer restart handling queues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses timer_delete(), which does not wait for a callback already running on another CPU. Such a callback can reach sctp_sf_t4_timer_expire() after the purge and dereference NULL. Clear addip_last_asconf after releasing the cached chunk, and make sctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding ASCONF remains. Fixes: a000c01e60e4 ("sctp: stop pending timers and purge queues when peer restart asoc") Cc: stable@vger.kernel.org Suggested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260809043806.2768302-1-yangyx22@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-12sctp: clear new_transport when removing a peerQing Ming
sctp_process_asconf_param() stores a newly added peer transport in asoc->new_transport. After all parameters in the ASCONF chunk have been processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the new transport. An authenticated ASCONF from a remote SCTP peer can add a transport and remove it again with a wildcard DEL-IP parameter in the same chunk. The wildcard deletion preserves the transport on which the ASCONF arrived, but removes the newly added transport through sctp_assoc_del_nonprimary_peers(). The removal does not clear asoc->new_transport, leaving it pointing to the removed transport. sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk->transport points to the removed transport without holding a transport reference. During local address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on control_chunk_list. After the transport is freed by RCU, a successful ASCONF_ACK for the replacement address releases the queued HEARTBEAT and sctp_outq_select_transport() reads the freed transport's state. The issue was found during a static audit of SCTP objects. With an authenticated peer, the reproducer triggered the same KASAN report in 2 of 2 unpatched runs on a KASAN-enabled netdev/main kernel: BUG: KASAN: slab-use-after-free in sctp_outq_select_transport Read of size 4 at addr ffff88800b9bd95c by task python3/197 Call Trace: sctp_outq_select_transport+0x549/0x8b0 [sctp] sctp_outq_flush+0x306/0x2c60 [sctp] sctp_transport_immediate_rtx+0xaf/0x260 [sctp] sctp_process_asconf_ack+0xa48/0xf70 [sctp] Allocated by task 197: sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] Last potentially related work creation: __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp] sctp_process_asconf+0xd9c/0x1090 [sctp] The first invalid access was a four-byte read of transport->state at net/sctp/outqueue.c:833. The same reproducer completed the full authenticated ASCONF and local-address replacement sequence with this change without a KASAN report or oops. Clear new_transport when its peer is removed, before it can be used to create the HEARTBEAT. Fixes: 6af29ccc223b ("sctp: Bundle HEAERTBEAT into ASCONF_ACK") Cc: stable@vger.kernel.org Signed-off-by: Qing Ming <a0yami@mailbox.org> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260811152803.5629-1-a0yami@mailbox.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-12libceph: Avoid using invalid osd indices from primary_tempRaphael Zimmer
A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ] Cc: stable@vger.kernel.org Fixes: 5e8d4d36bf23 ("libceph: add support for primary_temp mappings") Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-08-12libceph: fix OOB read in decode_watchers() via missing bounds checkPavitra Jha
ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ] Cc: stable@vger.kernel.org Fixes: a4ed38d7a180 ("libceph: support for CEPH_OSD_OP_LIST_WATCHERS") Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-08-12libceph: fix multiple unsafe decodes in decode_locker()Pavitra Jha
decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ] Cc: stable@vger.kernel.org Fixes: d4ed4a530562 ("libceph: support for lock.lock_info") Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-08-12libceph: tolerate addrvecs with multiple entries of the same typeKefu Chai
ceph_decode_entity_addrvec() rejects any addrvec containing more than one entry that matches the requested msgr type (LEGACY or MSGR2), logging "another match of type N in addrvec" and returning -EINVAL. Some admin tooling (e.g. pveceph mon create from Proxmox VE) generates addrvecs with multiple same-type entries when public_network lists more than one CIDR: it picks one local IP per subnet and emits both a v2 and a v1 entry for each IP. Monmaps shaped this way cause: libceph: mon0 (1)10.10.10.15:6789 session established libceph: another match of type 1 in addrvec libceph: problem decoding monmap, -22 No Ceph code uses the extra entries: since Nautilus, the userspace messenger (AsyncMessenger) unconditionally picks the first address of the requested type and ignores any subsequent matches. Match that behavior: use the first matching entry and silently skip any subsequent ones. This is a compatibility fix for existing deployments and does not enable dual-stack or multi-subnet address selection. [ idryomov: tweak ceph_decode_entity_addrvec() comment ] Cc: stable@vger.kernel.org Fixes: a5cbd5fc22d5 ("libceph, ceph: get and handle cluster maps with addrvecs") Link: https://bugzilla.proxmox.com/show_bug.cgi?id=7518 Signed-off-by: Kefu Chai <k.chai@proxmox.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-08-11mptcp: implemented OoO queue pruningPaolo Abeni
When moving incoming skbs in the msk receive queue and the latter is above limits, prune it as needed quite alike what TCP is doing at the subflow level. The main difference relies in the stop condition: since MPTCP does not perform collapsing, it's better off dropping the bare minimum to fit the (newer) incoming packet. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Tested-by: Gang Yan <yangang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-7-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: avoid code duplication in __mptcp_move_skb()Paolo Abeni
Alike TCP, MPTCP handles in-sequence packets and partially overlapping ones in a very similar way: we can use the same path to handle both, avoiding some code duplication. This will also make the next patch simpler. 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/20260807-net-next-mptcp-oooq-pruning-v3-6-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: enforce hard limit on backlog flushingPaolo Abeni
Currently a wild producer could keep the backlog flushing operation spinning for an unbound time. Since the previous patch, the amount of data present in the backlog is hard-limited. Move the backlog len update at the end of the flush loop to prevent it spinning forever. Also, no need to splice back the remaining skbs list into the backlog, as such list is always empty after each backlog processing loop. 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/20260807-net-next-mptcp-oooq-pruning-v3-5-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: explicitly drop over memory limitsPaolo Abeni
Currently the enforcement of the rcvbuf constraint is implemented when moving the skbs into the msk receive or OoO queue, keeping the incoming skbs in the subflow queue when over limits. Under significant memory pressure the above can cause permanent data transfer stalls, as the skb needed to make forward progress can be stuck in a subflow queue. Over memory limits, drop the incoming skb, relying on MPTCP-level retransmissions. Note that fallback socket must perform the limit before the skb reaches the subflow-level queue, as dropping an in-sequence already acked skb would break the stream. This is not a complete fix for the stall issue, as the drop strategy needs refinements that will come in the next patches. 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/20260807-net-next-mptcp-oooq-pruning-v3-4-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: let the retrans scheduler do its jobPaolo Abeni
Currently the MPTCP core enforces that when MPTCP-level retrans timer fires, at most a single dfrag is retransmitted. In some corner-cases, it may be necessary to retransmit multiple dfrags, and the MPTCP socket will need to wait multiple retrans timeout to accomplish that. Remove the mentioned constraint, allowing to transmit multiple dfrags per retrans period, as long as the scheduler keeps selecting subflows for retransmissions and pending data is available in the rtx queue. The default scheduler will transmit a dfrag per available subflow. Tested-by: Gang Yan <yangang@kylinos.cn> Tested-by: Geliang Tang <geliang@kernel.org> Acked-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-3-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: move the stale logic out of retrans schedulerPaolo Abeni
This allow separating the stale logic invocation and the retrans scheduler, and will simplify the next patch. It's also a cleaner design as the retrans scheduler has currently too many side effects. As a possible downside, the retrans work will now traverse the subflows list additional times; that does not matter much, as this is slowpath. While at it, pick more accurate names for the involved helpers and explicitly note that the per subflow stale data is under msk socket lock protection. The scheduler and the stale logic may observe different subflow statues, as no subflow lock is acquired. This is intentional and not harmful, worst case leading to slower retransmissions. 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/20260807-net-next-mptcp-oooq-pruning-v3-2-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11mptcp: move the retrans loop to a separate helperPaolo Abeni
This is a cleanup in order to make the next patch simpler. No functional change intended. Tested-by: Gang Yan <yangang@kylinos.cn> Tested-by: Geliang Tang <geliang@kernel.org> Acked-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-1-dbc1eb853cc3@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11Merge tag 'nf-26-08-10' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following patchset contains Netfilter/IPVS fixes for net. Still large batch for this late -rc cycle but at least half of these fixes in this batch have been cooking for several weeks before: 1) Fix race between ipset list:set GC and swap, use write_lock instead of rcu read lock section when accessing the index to ensure interference with ip_set_swap(), from Xiang Mei. 2) Release template conntrack in bridge conntrack when packet is neither IPv4 nor IPv6 before setting skb as untracked. From Zhiling Zou. 3) A series of 3 patches for IPVS to address sashiko reports: Schedulers read destination overload state while connection accounting and destination configuration can update it concurrently. The first patch adds a single total connection counter. The second patch uses it to identify threshold crossings precisely, and updates OVERLOAD at the crossings and on a threshold edit under dst_lock. The third patch moves configuration-controlled AVAILABLE to a separate cflags word, so it cannot clobber OVERLOAD through an unrelated read-modify-write update. 4) Log invalid packets in TCP and SCTP connection tracking to address a deadlock when nfnetlink_log is used as logging backend and the nfnetlink_log conntrack glue support is used. From Zihan Xi. 5) Wait for rcu grace period before releasing pernet state in nfnetlink_log, otherwise packets can end up access already released memory, triggering UaF. From Florian Westphal. 6) IPVS needs to reset IP information in control buffer in skbuff when encapsulating IP packets in ICMP, from Kyle Zeng. 7) IPVS needs to validate ihl field of inner headers in when handling ICMP response, from Julian Anastasov. 8) Remove a WARN_ON_ONCE reachable from the nf_tables hardware offload when triggering ENOMEM on GFP_KERNEL allocation, from Alexey Velichayshiy. 9) Publish reply tuple into the flowtable hashtable first, otherwise GC might walk over a released tuple when insertion of the original tuple fail. From Jeremy Jean. 10) Elide counter increment when replacing an ipset element, from Florian Westphal. 11) Remove unneeded ipset accounting resets on destruction/flush, from Florian Westphal. * tag 'nf-26-08-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: ipset: let destroy callbacks adjust ext mem size netfilter: ipset: fix list type element drift bug netfilter: flowtable: publish GC-visible tuple last netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path ipvs: revalidate ihl to prevent out-of-bounds access ipvs: clear IPv4 options after rebasing tunnel ICMP errors netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state netfilter: nf_conntrack: defer invalid log until after unlock ipvs: separate destination availability state ipvs: properly update the overload flag on dest edit ipvs: add totalconns for dest netfilter: bridge: release template ct on non-IP path netfilter: ipset: fix refcount race between list:set GC and swap ==================== Link: https://patch.msgid.link/20260810190621.894119-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11net/sched: cls_u32: skip hash tables in u32_bind_class()Zhang Changzhong
u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check. Fixes: 07d79fc7d94e ("net_sched: add reverse binding for tc class") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/1786089038-36366-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11net/sched: act_api: fix TOCTOU NULL deref on a->goto_chainJamal Hadi Salim
tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking rcu_access_pointer(a->goto_chain) and then calling tcf_action_goto_chain_exec(), which does a second, independent rcu_dereference_bh(a->goto_chain) read and immediately dereferences chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact replace path) can clear a->goto_chain between the two reads, so the second read returns NULL and tcf_action_goto_chain_exec() dereferences NULL. Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain in tcf_action_exec(), checking it once for NULL, and passing the resulting chain pointer into tcf_action_goto_chain_exec(). This turns the split check/use into a single check/use on one value. Fixes: ee3bbfe806cd ("net/sched: let actions use RCU to access 'goto_chain'") Reported-by: vega@nebusec.ai Tested-by: Victor Nogueira <victor@mojatatu.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Davide Caratti <dcaratti@redhat.com> Link: https://patch.msgid.link/20260809090928.868186-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11devlink: add generic device max_sfs parameterNikolay Aleksandrov
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 <nikolay@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260806073037.3001886-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11af_packet: Don't send zero-byte data in tpacket_snd().Eric Dumazet
syzbot reported a WARNING in __dev_queue_xmit() triggered via tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Call Trace: <TASK> dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 When sending 0-byte packets via TPACKET ring buffer on devices with no hard header (e.g. dev->hard_header_len == 0), tpacket_fill_skb() populates an skb with skb->len == 0 and returns 0. tpacket_snd() then forwards this empty skb to packet_xmit(), causing __dev_queue_xmit() to hit skb_assert_len(skb). Similar checks exist in packet_snd() via commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") and in packet_sendmsg_spkt() via commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). Return -EINVAL in tpacket_fill_skb() when skb->len is zero to reject zero-length packets in tpacket_snd(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+30b93b6845b19cc38581@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a79e807.01d0871a.3a0d52.00ac.GAE@google.com/T/#u Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://patch.msgid.link/20260810150447.1220864-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-11nfc: nci: free destination parameters when closing a connectionLinmao Li
When a connection is closed, nci_core_conn_close_rsp_packet() frees conn_info but not conn_info->dest_params, which is a separate devm allocation. Each connect/close cycle leaks one dest_params until the NFC device is removed. Free dest_params along with conn_info. Fixes: 9b8d1a4cf2aa ("nfc: nci: Add an additional parameter to identify a connection id") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260721023518.1697625-1-lilinmao@kylinos.cn Signed-off-by: David Heidelberg <david@ixit.cz>