summaryrefslogtreecommitdiff
path: root/net
AgeCommit message (Collapse)Author
2026-06-09SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlistsChuck Lever
The crypto/krb5 library accepts data in scatterlist form, but the GSS-API layer presents RPC payloads as struct xdr_buf. Bridge that gap with a pair of helper functions: xdr_buf_to_sg() - populate a caller-supplied scatterlist array from a byte range xdr_buf_to_sg_alloc() - populate a caller-supplied inline scatterlist, chaining to a heap- allocated overflow for large payloads The inline array (typically stack-allocated at eight entries) covers the common case of small RPCs with no heap allocation on the encrypt/decrypt path. Only buffers spanning many pages incur a kmalloc for the chained extension. The segment-walking logic follows the same head, page array, tail traversal as xdr_process_buf(), but populates a scatterlist directly rather than invoking a per-segment callback. sg_next() traversal makes the walker safe for chained scatterlists. Once subsequent patches reroute all per-message crypto operations through crypto/krb5, xdr_process_buf() loses its last callers and is removed. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton <jlayton@kernel.org> Acked-by: Anna Schumaker <anna.schumaker@hammerspace.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2026-06-09SUNRPC: Add crypto/krb5 enctype lookup to krb5_ctxChuck Lever
Each krb5_ctx currently points to a gss_krb5_enctype, the rpcsec_gss_krb5 module's own enctype descriptor. To begin using the common crypto/krb5 library, store a pointer to the corresponding struct krb5_enctype (from <crypto/krb5.h>) as well. The lookup is performed in gss_import_v2_context() immediately after the existing gss_krb5_lookup_enctype() call. If crypto_krb5_find_enctype() cannot find a matching enctype the context import fails, ensuring the module never operates with a partially-initialized krb5_ctx. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton <jlayton@kernel.org> Acked-by: Anna Schumaker <anna.schumaker@hammerspace.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2026-06-09SUNRPC: Add Kconfig dependency on CRYPTO_KRB5Chuck Lever
The rpcsec_gss_krb5 module currently contains its own Kerberos 5 crypto implementation (key derivation, encryption, checksumming) that duplicates functionality available in the common crypto/krb5 library. As a first step toward migrating to that library, add a Kconfig select so that building rpcsec_gss_krb5 pulls in the common Kerberos 5 crypto support. The per-enctype Kconfig options (AES_SHA1, CAMELLIA, AES_SHA2) remain: they continue to gate which encryption types are offered by the GSS mechanism. The individual crypto algorithm selects they carry become redundant once the migration is complete, since CRYPTO_KRB5 already selects all needed ciphers and hashes. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton <jlayton@kernel.org> Acked-by: Anna Schumaker <anna.schumaker@hammerspace.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2026-06-09net: ethtool: optionally skip rtnl_lock on IOCTL pathJakub Kicinski
Convert the IOCTL path similarly to how we converted Netlink. The device lookup gets a little hairy. We could take rtnl_lock unconditionally and drop it before calling the driver (this would avoid the reference + liveness check). But I think being able to make progress even if rtnl is dead-locked is quite useful. First extra concern is handling features. List all the cmds which modify features and always take rtnl_lock. We could fold this list into ethtool_ioctl_needs_rtnl() but seems cleaner to keep ethtool_ioctl_needs_rtnl() driver-related. If a driver changed features and we were not holding rtnl_lock - warn about it. It can only happen on buggy ops locked drivers (buggy because they should have set appropriate "I need rtnl for op X" bit). Second wrinkle is the PHY ID hack which drops the locks while sleeping. Convert its static "busy" variable which used to be protected by rtnl_lock to a field in struct ethtool_netdev_state. This feature is about identifying an adapter or a port within a system, so being able to blink multiple LEDs at the same time is likely not very useful in practice. But it's the simplest fix, we can add a mutex if someone thinks a system should only be ID'ing one port at a time. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-12-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: ioctl: concentrate the lockingJakub Kicinski
Add another layer of helper functions to make upcoming locking changes easier. Otherwise we'd need a pretty complex goto structure. netdev instance lock is now taken slightly sooner but that should not be an issue since rtnl_lock is already held, anyway. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-11-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock in RSS context handlersJakub Kicinski
Skip rtnl_lock in RSS context handlers if device is ops-locked. Fairly trivial conversion. bnxt needed rtnl_lock for changing the main context but looks like additional contexts are fine without it. Note (for review bots?) that ethnl_ops_begin() checks whether the device is still registered. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-10-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock in ethnl_act_module_fw_flash()Jakub Kicinski
Module firmware flashing reads SFF-8024 identifier bytes via .get_module_eeprom_by_page(). Other than that it modifies a bit in the netdev->ethtool struct. Both should be ops-locked at this point. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-9-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock in ethnl_tsinfo_dumpit()Jakub Kicinski
ethnl_tsinfo_dumpit() iterates netdevs and per-netdev PHY topology calling ops->get_ts_info(). Switch to the "ops compat locking" helpers which take either rtnl_lock or instance lock, depending on what the device needs. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-8-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock in cable test handlersJakub Kicinski
Skip rtnl_lock in cable test handlers. This is really a noop since no ops locked device supports these. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-7-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock on Netlink path for SET opsJakub Kicinski
Make ethtool not take rtnl_lock for SET commands when operation is performed on an ops-locked driver. cfg/cfg_pending are now ops-locked, since only ethtool modifies them. Some SET driver callbacks will still need rtnl_lock, most notably those which may end up calling netdev_update_features() or the qdisc layer (via netif_set_real_num_tx_queues()). Let drivers selectively opt back into the rtnl_lock with a new bitfield in ops. We need two helpers since Netlink and ioctl cmds have different values. Keep the helpers side by side in common.h to make sure they get updated together, even tho they will only get called from ioctl.c and netlink.c. SET commands which don't use ethnl_default_set_doit() are converted by subsequent commits. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock on Netlink path for GET opsJakub Kicinski
ethnl_default_doit() and ethnl_default_dump_one() are both used exclusively for GET callbacks (former to get info for a single device or get global strings). ops-locked devices don't need rtnl_lock for GET callbacks, stop taking it. Introduce an opt-out mechanism for devices which use phylink (fbnic) since phylink currently depends on rtnl_lock protection. Subsequent patches will add more exceptions, anyway. Practically the new helpers for judging if command needs rtnl_lock could also call netdev_need_ops_lock() but I find that it makes the code in the callers slightly less obvious. Add a helper for IOCTLs already, even tho it's unused so that we can keep them in sync as the series progresses. This is the first user-visible step of moving ethtool ops out from under rtnl. Subsequent patches do the same for SET ops, as well as the ioctl path. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: make dev->hwprov ops-protectedJakub Kicinski
dev->hwprov tracks the active hwtstamp provider for the device. Make it ops protected (instance lock if the netdev driver opts into holding instance lock around callbacks, otherwise rtnl_lock). hwprov is written and read in: - drivers/net/phy/phy_device.c phydev and ops protection don't currently mix, add a comment - net/ethtool/ as of now holds both rtnl lock and ops lock, this one will soon only hold one lock or the other read in: - net/core/dev_ioctl.c holds both rtnl lock and ops lock - net/core/timestamping.c RCU reader The new netdev_ops_lock_dereference() helper does not have "compat" in the name. The name would be quite long and I think in this case it should be obvious that we need _a_ lock. netdev_lock_dereference() already exists and means dev->lock is always expected. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: relax ethnl_req_get_phydev() locking assertionJakub Kicinski
phydev <> netdev linking and lifecycle depends on rtnl_lock. We want to switch to instance locks for most ethtool ops. Let's add an assert that ops locked devices don't use phydev today. If one does we can either opt the phy ops out of being purely ops locked, or do deeper surgery to make phy locking ops-compatible. I don't think there's any fundamental challenge to make that work. Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: serialize broadcast notification sequence allocationJakub Kicinski
ethnl_bcast_seq is a global counter stamped into the nlmsg_seq field of every multicast notification, allowing userspace to detect dropped messages. Today the ordering is achieved by using rtnl_lock(). Moving forward we will want ethtool ops to run under just the netdev instance lock so to establish ordering we need a separate lock for notifications. With the netdev instance locks operations on different devices may bypass each other but the expectation is that it should not matter. What we need to prevent is: - notification IDs getting out of order - operations on one device getting out of order For simplicity defer allocating the ID of the notification right before the notification is delivered. This removes the need for special handling in ethnl_rss_create_send_ntf(). Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09esp: fix page frag reference leak on skb_to_sgvec failureAlessandro Schino
In esp_output_tail(), when esp->inplace is false, the old skb page frags are replaced with a new page from the xfrm page_frag cache The source scatterlist (sg) is built from the old frags before the replacement, and esp_ssg_unref() is responsible for releasing the old page references after the crypto operation completes However, if the second skb_to_sgvec() call (which builds the destination scatterlist from the new page) fails, the code jumps to error_free which only calls kfree(tmp). The old page frag references captured in the source scatterlist are never released: 1 sg[] is built from old frags via skb_to_sgvec() (no extra get_page) 2 nr_frags is set to 1 and frag[0] is replaced with the new page 3 Second skb_to_sgvec() fails -> goto error_free Fix this by adding a bool parameter to esp_ssg_unref() that, when true, unconditionally unrefs the source scatterlist frags. Since req->src is not yet initialized by aead_request_set_crypt() at the point of the error, the source scatterlist is obtained directly via esp_req_sg() Existing callers pass false to preserve the original behavior The same issue exists in both esp4 and esp6 as the code is identical Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible") Signed-off-by: Alessandro Schino <7991aleschino@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-06-09ipv4: igmp: annotate data-races around timer-related fieldsYuyang Huang
/proc/net/igmp walks the multicast list locklessly under RCU and reads timer-related fields (im->tm_running, im->reporter, im->timer.expires) to print the timer state of multicast memberships. Concurrently, these fields are modified under im->lock spinlock in timer management paths (igmp_stop_timer(), igmp_start_timer(), and igmp_timer_expire()). Fix this intentional lockless snapshot by annotating the lockless reads with READ_ONCE() and the updates with WRITE_ONCE(). Signed-off-by: Yuyang Huang <yuyanghuang@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260605014318.3890804-3-yuyanghuang@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09ipv4: igmp: annotate data-races around in_dev->mc_countYuyang Huang
/proc/net/igmp walks the multicast list for IPv4 interfaces locklessly under RCU and prints state->in_dev->mc_count. Concurrently, device init/destruction and multicast join/leave paths update the count under the RTNL lock. Fix this intentional lockless snapshot by annotating the read with READ_ONCE() and the updates with WRITE_ONCE(). Signed-off-by: Yuyang Huang <yuyanghuang@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260605014318.3890804-2-yuyanghuang@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09netconsole: do not dequeue pooled skbs that cannot satisfy lenBreno Leitao
find_skb() falls back to np->skb_pool when the GFP_ATOMIC alloc_skb() fails. The pool is refilled by refill_skbs(), which always allocates buffers of MAX_SKB_SIZE (ethhdr + iphdr + udphdr + MAX_UDP_CHUNK == 1502 bytes). netconsole, however, computes the requested length dynamically as total_len + np->dev->needed_tailroom If the egress device declares a non-zero needed_tailroom (e.g. some tunnel or hardware accelerator devices), the required length can exceed MAX_SKB_SIZE. The pooled skb is then handed back to the caller, which immediately performs skb_put(skb, len), trips the tail > end check, and triggers skb_over_panic(). Leave the normal alloc_skb(len, GFP_ATOMIC) path untouched -- the slab allocator can still satisfy oversized requests when memory is available, so senders to devices with non-zero needed_tailroom keep working in the common case. Only the pool fallback is gated: when alloc_skb() failed and len exceeds the pool buffer size, skip the skb_dequeue() instead of burning a pre-allocated skb on a request that would later trip skb_over_panic(). Reserving pool entries for requests they can actually satisfy also keeps the panic path, which depends on the pool being primed, intact. When that drop happens, emit a rate-limited net_warn() so the user notices that netconsole is unable to push messages on the egress device. The warn is skipped under in_nmi() for the same reason schedule_work() is: printk machinery taken by net_warn_ratelimited() is not NMI-safe and would risk recursing into the same nbcon console we are servicing. MAX_SKB_SIZE / MAX_UDP_CHUNK were private to net/core/netpoll.c. Move them to include/linux/netpoll.h so netconsole can reference the same definition that refill_skbs() uses, keeping the two in sync by construction. The header now pulls in <linux/ip.h> and <linux/udp.h> explicitly so MAX_SKB_SIZE remains self-contained for any future user. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260604-netcons_fix_before_move-v3-2-ab055b3a6aa5@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09rxrpc: Fix the ACK parser to extract the SACK table for parsingDavid Howells
Fix modification of the received skbuff in rxrpc_input_soft_acks() and a potential incorrect access of the buffer in a fragmented UDP packet (the packet would probably have to be deliberately pre-generated as fragmented) when AF_RXRPC tries to extract the contents of the SACK table by copying out the contents of the SACK table into a buffer before attempting to parse AF_RXRPC assumes that it can just call skb_condense() and then validly access the SACK table from skb->data and that it will be a flat buffer - but skb_condense() can silently fail to do anything under some circumstances. Note that whilst rxrpc_input_soft_acks() should be able to parse extended ACKs, the rest of AF_RXRPC doesn't currently support that. Further, there's then no need to call skb_condense() in rxrpc_input_ack(), so don't. Fixes: d57a3a151660 ("rxrpc: Save last ACK's SACK table rather than marking txbufs") Reported-by: Michael Bommarito <michael.bommarito@gmail.com> Link: https://lore.kernel.org/r/20260513180907.2061972-1-michael.bommarito@gmail.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Eric Dumazet <edumazet@google.com> cc: "David S. Miller" <davem@davemloft.net> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org cc: stable@kernel.org Link: https://patch.msgid.link/105362.1780573560@warthog.procyon.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-08net: openvswitch: fix possible kfree_skb of ERR_PTRAdrian Moreno
After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking. If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value. Fixes: 893f139b9a6c ("openvswitch: Minimize ovs_flow_cmd_new|set critical sections.") Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Reviewed-by: Aaron Conole <aconole@redhat.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Link: https://patch.msgid.link/20260604121946.942164-1-amorenoz@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08tls: Flush backlog before waiting for a new recordChuck Lever
While lock_sock is held, incoming TCP segments land on sk->sk_backlog rather than sk->sk_receive_queue. tls_rx_rec_wait() inspects only sk_receive_queue, so backlog data remains invisible. For non-blocking callers (read_sock, and recvmsg or splice_read with MSG_DONTWAIT) this causes a spurious -EAGAIN. For blocking callers it forces an unnecessary sleep/wakeup cycle. Flush the backlog inside tls_rx_rec_wait() before checking sk_receive_queue so the strparser can parse newly-arrived segments immediately. On the next loop iteration tls_read_flush_backlog() may redundantly flush, but this path is cold and the cost is negligible. Backlog processing can run tcp_reset(), which calls tcp_done_with_error() to set sk->sk_err = ECONNRESET and then tcp_done() to set sk->sk_shutdown = SHUTDOWN_MASK. The pre-existing top-of-loop sk_err check already ran before the flush, so the freshly-set error would be masked by the next-line sk_shutdown test returning 0 (EOF). Re-check sk_err immediately before the sk_shutdown test so a connection abort surfaces as -ECONNRESET rather than a clean EOF. Commit f508262ae9f2 ("tls: Preserve sk_err across recvmsg() when data has been copied") gave the top-of-loop sk_err check a has_copied split. The recheck applies the same handling: when the caller has already copied bytes, sk_err is reported but preserved so the error surfaces on the next call; otherwise sock_error() consumes it so the error is reported exactly once. Suggested-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/netdev/ahgHgQ84RCc8uYrG@krikkit/ Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20260604-tls-read-sock-v12-6-b114efa6e3e2@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08tls: Suppress spurious saved_data_ready on all receive pathsChuck Lever
Each record release via tls_strp_msg_done() triggered tls_strp_check_rcv(), which called tls_rx_msg_ready() and fired saved_data_ready(). During a multi-record receive, the first N-1 wakeups are pure overhead: the caller is already running and will pick up subsequent records on the next loop iteration. The recvmsg and splice_read paths share this waste. Suppress per-record notifications and emit a single one on reader exit. tls_rx_rec_done() releases the current record and parses the next without announcing; tls_strp_check_rcv() gains a bool announce parameter so callers can request the quiet form. tls_rx_reader_release() fires the deferred announce on exit through tls_rx_msg_maybe_announce(), an idempotent helper that calls saved_data_ready() only when a record is parsed and has not yet been announced. To keep the final notification idempotent against records that the BH or the worker has already announced, tls_strparser gains a msg_announced bit. tls_rx_msg_maybe_announce() sets the bit when firing saved_data_ready(); the bit is cleared whenever the parsed record is wiped, by tls_strp_msg_consume() on consumption or by tls_strp_msg_load() when the lower socket loses bytes from under the parse. A second call for the same parsed record -- as when recvmsg() satisfies the request from ctx->rx_list without touching the strparser -- becomes a no-op. With no remaining callers, tls_strp_msg_done() is removed. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20260604-tls-read-sock-v12-5-b114efa6e3e2@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08tls: Factor tls_strp_msg_consume() from tls_strp_msg_done()Chuck Lever
tls_strp_msg_done() conflates releasing the current record with checking for the next one via tls_strp_check_rcv(). A subsequent patch needs to release a record without immediately triggering that check, so the release step is separated into tls_strp_msg_consume(). tls_strp_msg_done() is preserved as a wrapper for existing callers. Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20260604-tls-read-sock-v12-4-b114efa6e3e2@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08tls: Move decrypt-failure abort into tls_rx_one_record()Chuck Lever
Three receive paths -- recvmsg, read_sock, and splice_read -- each follow tls_rx_one_record() with the same tls_err_abort() call. Consolidate the abort into tls_rx_one_record() so the decrypt-and-abort sequence lives in one place. A tls_check_pending_rekey() failure after successful decryption no longer triggers tls_err_abort(). That path fires only when skb_copy_bits() fails on a valid skb, which is not a realistic scenario. Suggested-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Link: https://patch.msgid.link/20260604-tls-read-sock-v12-3-b114efa6e3e2@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08tls: Re-present partially-consumed records in tls_sw_read_sock()Chuck Lever
The tls_sw_read_sock() loop releases the current skb whether read_actor() consumed the full record or only a prefix. When the actor takes only part of the record and leaves desc->count non-zero, the remainder is lost: skb is neither requeued nor freed, and the next iteration overwrites it during dequeue or tls_rx_rec_wait(). No mainline consumer reaches this path today. The only in-tree TLS read_sock user is nvme/tcp, whose actor nvme_tcp_recv_skb() loops until the input length is exhausted and returns either the full length or a negative error. The path becomes reachable with the upcoming NFSD svcsock receive built on read_sock_cmsg. Its data actor, svc_tcp_recv_actor(), parses an RPC fragment stream incrementally and returns at fragment boundaries. When a TLS record carries the tail of one RPC fragment plus the head of the next, the actor returns fewer bytes than offered while leaving desc->count non-zero, and without re-presentation the trailing fragment header vanishes. __tcp_read_sock() handles the equivalent case for plain TCP by leaving the unread bytes available for the next iteration to re-present, via sequence-number re-lookup. Adopt the same loop-level behavior: when read_actor() consumes only part of the record, update rxm->offset and rxm->full_len and requeue the skb to the head of rx_list so the next iteration re-presents the unread bytes. Switch the open-ended for-loop to "while (desc->count)" so the partial- and full-consume arms share a single exit check and read_actor() is not re-invoked once desc->count is exhausted. Cc: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20260604-tls-read-sock-v12-2-b114efa6e3e2@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08tls: Avoid evaluating freed skb in tls_sw_read_sock() loopChuck Lever
tls_sw_read_sock() ends its receive loop with while (skb), but the else branch in the body calls consume_skb(skb) before the predicate is re-evaluated. A pointer becomes indeterminate when the object it points to reaches end-of-lifetime (C2011 6.2.4p2), and using an indeterminate value is undefined behavior (Annex J.2). The pointer is not dereferenced today -- the predicate either exits the loop or skb is overwritten at the top of the next iteration -- but any future change that adds a dereference between consume_skb() and the predicate would silently introduce a use-after-free. Replace the do/while form with an explicit for(;;) loop so termination happens through a break statement rather than predicate evaluation of a freed pointer. Cc: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20260604-tls-read-sock-v12-1-b114efa6e3e2@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: garp: reload skb header pointers after pskb_may_pull()David Carlier
garp_pdu_parse_attr() keeps a pointer into the skb linear area across pskb_may_pull(skb, ga->len), and garp_pdu_parse_msg() dereferences gm on every loop iteration even though the nested parse may pull again. pskb_may_pull() can reallocate the skb head, which would leave those pointers stale. This is not reachable today: GARP PDUs arrive via the 802.2 LLC SAP path, where llc_fixup_skb() already pulls and trims the whole payload into the linear area, so the inner pulls never reallocate. Reload ga after the pull and snapshot gm->attrtype into a local anyway, to harden the parser and match the skb_header_pointer() discipline used by mrp.c. No functional change. Signed-off-by: David Carlier <devnexen@gmail.com> Link: https://patch.msgid.link/20260604141925.237746-1-devnexen@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ipv6: sit: reload inner IPv6 header after GSO offloadsKyle Zeng
ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb. Fixes: 14909664e4e1 ("sit: Setup and TX path for sit/UDP foo-over-udp encapsulation") Signed-off-by: Kyle Zeng <kylebot@openai.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot+6eb9ca986d80f6f88cf9@syzkaller.appspotmail.com Link: https://patch.msgid.link/20260605073448.6524-1-kylebot@openai.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: qrtr: fix refcount saturation and potential UAF in qrtr_port_removeMingyu Wang
In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: <TASK> qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... </TASK> Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.) Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260604064801.1180388-1-w15303746062@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08netdev: fix double-free in netdev_nl_bind_rx_doit()Jakub Kicinski
Sashiko flags that genlmsg_reply() always consumes the skb. The error path calls nlmsg_free(rsp) so we can't jump directly to it. Let's not unbind, just propagate the error to the user. This is the typical way of handling genlmsg_reply() failures. They shouldn't happen unless user does something silly like calling the kernel with an already-full rcvbuf. Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: 170aafe35cb9 ("netdev: support binding dma-buf to netdevice") Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: phonet: free phonet_device after RCU grace periodSantosh Kalluri
phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type. Fixes: eeb74a9d45f7 ("Phonet: convert devices list to RCU") Cc: stable@vger.kernel.org Signed-off-by: Santosh Kalluri <santosh.kalluri129@gmail.com> Acked-by: Rémi Denis-Courmont <remi@remlab.net> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: add pskb_may_pull() to skb_gro_receive_list()HanQuan
skb_gro_receive_list() calls skb_pull(skb, skb_gro_offset(skb)) without first ensuring the data is in the linear area via pskb_may_pull(). When the skb arrives via napi_gro_frags(), skb_headlen can be 0 (all data in page fragments) while skb_gro_offset is non-zero (after IP+TCP header parsing). The skb_pull() then decrements skb->len by skb_gro_offset but skb->data_len stays unchanged, hitting BUG_ON(skb->len < skb->data_len) in __skb_pull(). The UDP fraglist GRO path already contains this guard at udp_offload.c:749. Adding it to skb_gro_receive_list() itself provides centralized protection for all callers (TCP, UDP, and any future protocols), and ensures the precondition of skb_pull() is satisfied before it is called. On pskb_may_pull() failure, set NAPI_GRO_CB(skb)->flush = 1 so the skb is not held as a new GRO head and is instead delivered through the normal receive path, matching the UDP handling. Fixes: 8d95dc474f85 ("net: add code for TCP fraglist GRO") Reported-by: HanQuan <eilaimemedsnaimel@gmail.com> Reported-by: MingXuan <bwnie0730@outlook.com> Signed-off-by: HanQuan <eilaimemedsnaimel@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Replace RTNL with a dedicated mutex for MFC.Kuniyuki Iwashima
ip6mr does not have rtnetlink interface for MFC unlike ipmr, which uses dev_get_by_index_rcu() to set struct mfcctl.mfcc_parent. ip6mr_mfc_add() and ip6mr_mfc_delete() are called under RTNL from ip6_mroute_setsockopt() only. There are no RTNL dependant, but ip6_mroute_setsockopt() reuses RTNL just for mrt->mfc_hash and mrt->mfc_cache_list. Let's replace RTNL with a new per-netns mutex. Later, ip6mr_notifier_ops and ipmr_seq will be moved under CONFIG_IPV6_MROUTE. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-15-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Remove RTNL in ip6mr_rules_init() and ip6mr_net_init().Kuniyuki Iwashima
When ip6mr_free_table() is called from ip6mr_rules_init() or ip6mr_net_init(), the netns is not yet published. Thus, no device should have been registered, and mroute_clean_tables() will not call mif6_delete(), so unregister_netdevice_many() is unnecessary. unregister_netdevice_many() does nothing if the list is empty, but it requires RTNL due to the unconditional ASSERT_RTNL() at the entry of unregister_netdevice_many_notify(). Let's remove unnecessary RTNL and ASSERT_RTNL() and instead add WARN_ON_ONCE() in ip6mr_free_table(). Note that we use a local list for the new WARN_ON_ONCE() because dev_kill_list passed from ip6mr_rules_exit_rtnl() may have some devices when other ops->init() fails after ipmr durnig setup_net(). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-14-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Convert ip6mr_net_exit_batch() to ->exit_rtnl().Kuniyuki Iwashima
ip6mr_net_ops uses ->exit_batch() to acquire RTNL only once for dying network namespaces. ip6mr does not depend on the ordering of ->exit_rtnl() and ->exit_batch() of other pernet_operations (unlike fib_net_ops). Once ip6mr_free_table() is called and all devices are queued for destruction in ->exit_rtnl(), later during NETDEV_UNREGISTER, ip6mr_device_event() will not see anything in vif table and just do nothing. Let's convert ip6mr_net_exit_batch() to ->exit_rtnl(). We will remove RTNL and unregister_netdevice_many() in ip6mr_rules_init(). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-13-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Move unregister_netdevice_many() out of ip6mr_free_table().Kuniyuki Iwashima
This is a prep commit to convert ip6mr_net_exit_batch() to ->exit_rtnl(). Let's move unregister_netdevice_many() in ip6mr_free_table() to its callers. Now ip6mr_rules_exit() can do batching all tables per netns. Note that later we will remove RTNL and unregister_netdevice_many() in ip6mr_rules_init(). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-12-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Move unregister_netdevice_many() out of mroute_clean_tables().Kuniyuki Iwashima
This is a prep commit to convert ip6mr_net_exit_batch() to ->exit_rtnl(). Let's move unregister_netdevice_many() in mroute_clean_tables() to its callers. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-11-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Call fib_rules_unregister() without RTNL.Kuniyuki Iwashima
fib_rules_unregister() removes ops from net->rules_ops under spinlock, calls ops->delete() for each rule, and frees the ops. ip6mr_rules_ops_template does not have ->delete(), and any operation does not require RTNL there. Let's move fib_rules_unregister() from ip6mr_rules_exit() to ip6mr_net_exit(). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-10-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Free mr_table after RCU grace period.Kuniyuki Iwashima
Since default_device_exit_batch() is called after ->exit_rtnl(), idev->mc_ifc_work could finally call mroute6_is_socket() under RCU while ->exit_rtnl() is running. [0] With CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=n, ip6mr_fib_lookup() does not check if net->ipv6.mrt6 is NULL. If ip6mr_net_exit_batch() set net->ipv6.mrt6 to NULL and freed it, the mrt->mroute_sk access could result in null-ptr-deref or use-after-free. Let's prepare for that situation by applying RCU rule to ip6mr table similarly. !check_net(net) is added in ip6mr_cache_unresolved() and mroute_clean_tables() to synchronise the two by mfc_unres_lock so that ip6mr_cache_unresolved() will not queue skb after mroute_clean_tables() purged &mrt->mfc_unres_queue. rcu_read_lock() in reg_vif_xmit() is moved up to cover ip6mr_fib_lookup() as with ipmr. Link: https://lore.kernel.org/netdev/20260407184202.34cfe2d6@kernel.org/ #[0] Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-9-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: Remove rtnl_held of struct fib_dump_filter.Kuniyuki Iwashima
Commit 22e36ea9f5d7 ("inet: allow ip_valid_fib_dump_req() to be called with RTNL or RCU") introduced the rtnl_held field in struct fib_dump_filter to switch __dev_get_by_index() and dev_get_by_index_rcu() depending on the caller's context. This field served as an interim measure while we were incrementally converting all callers of ip_valid_fib_dump_req() to RCU. Now that all users (IPv4, IPv6, ipmr, ip6mr, and MPLS) have been converted to RCU, the field is no longer necessary. Let's remove it. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-8-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Convert ip6mr_rtm_dumproute() to RCU.Kuniyuki Iwashima
ip6mr_rtm_dumproute() calls mr_table_dump() or mr_rtm_dumproute(), and mr_rtm_dumproute() finally calls mr_table_dump(). mr_table_dump() calls the passed function, _ip6mr_fill_mroute(). _ip6mr_fill_mroute() is a wrapper for ip6mr_fill_mroute() to cast struct mr_mfc * to struct mfc6_cache *. ip6mr_fill_mroute() can already be called safely under RCU. Let's convert ip6mr_rtm_dumproute() to RCU. Now there is no user of the rtnl_held field in struct fib_dump_filter, and the next patch will remove it. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-7-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Convert ip6mr_rtm_getroute() to RCU.Kuniyuki Iwashima
ip6mr_rtm_getroute() calls __ip6mr_get_table(), ip6mr_cache_find(), and ip6mr_fill_mroute(). Once created, struct mr_table is not freed until netns dismantle, so it's safe under RCU. ip6mr_cache_find() iterates mrt->mfc_hash with rhl_for_each_entry_rcu(). struct mr_mfc is freed with call_rcu(), so this is also safe under RCU. ip6mr_fill_mroute() calls mr_fill_mroute(), which properly uses RCU helpers. Let's call them under RCU and register ip6mr_rtm_getroute() with RTNL_FLAG_DOIT_UNLOCKED. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-6-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Allocate skb earlier in ip6mr_rtm_getroute().Kuniyuki Iwashima
We will convert ip6mr_rtm_getroute() to RCU in the following patch, where __ip6mr_get_table() will be called under RCU. nlmsg_new() uses GFP_KERNEL and needs to be called before holding rcu_read_lock(). As a prep, let's move nlmsg_new() before __ip6mr_get_table(). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-5-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Use MAXMIFS in mr6_msgsize().Kuniyuki Iwashima
mr6_msgsize() calculates skb size needed for ip6mr_fill_mroute(). The size differs based on mrt->maxvif. We will drop RTNL for ip6mr_rtm_getroute() and mrt->maxvif may change under RCU. To avoid -EMSGSIZE, let's calculate the size with the maximum value of mrt->maxvif, MAXMIFS. struct rtnexthop is 8 bytes and MAXMIFS is 32, so the maximum delta is 256 bytes, which is small enough. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-4-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08ip6mr: Annotate access to mrt->mroute_do_{pim,assert,wrvifwhole}.Kuniyuki Iwashima
These fields in struct mr_table are updated in ip6_mroute_setsockopt() under RTNL: * mroute_do_pim * mroute_do_assert (MRT6_PIM is under RTNL while MRT6_ASSERT is lockless) * mroute_do_wrvifwhole However, ip6_mroute_getsockopt() does not hold RTNL and read the first two fields locklessly, and ip6_mr_forward() reads all the three under RCU. Let's use WRITE_ONCE() and READ_ONCE() for them. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260604224712.3209821-3-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net_sched: sch_fq: convert skb->tstamp if not monotonicWillem de Bruijn
FQ currently assumes skb->tstamp holds monotonic time, as used by TCP. Users with ns_capable CAP_NET_ADMIN can transmit skbs using SO_TXTIME with CLOCK_MONOTONIC, CLOCK_REALTIME or CLOCK_TAI clockids as of commit 80b14dee2bea ("net: Add a new socket option for a future transmit time.") More recently, skbs also gained tstamp_type to explicitly communicate the clockid of skb->tstamp, with commit 4d25ca2d6801 ("net: Rename mono_delivery_time to tstamp_type for scalabilty"), commit 1693c5db6ab8 ("net: Add additional bit to support clockid_t timestamp type") and a few others. Detect other clocks and convert to monotonic for use in FQ. That is, convert fq_skb_cb(skb)->time_to_send. Do not convert skb->tstamp itself. Network device clocks are more commonly synchronized to TAI. Conversion may be imprecise due to clock adjustment (e.g., adjfreq) between when SCM_TSTAMP is set and when it is converted in fq_enqueue. The common codepath is short, so skew will be well below common pacing operation. Even in edge cases, bursts (too soon) or beyond horizon (too late) are indistinguishable from network conditions. To which senders must be robust, as long as infrequent. Avoid overflow due to negative offsets becoming huge when converting from signed ktime_t to u64 time_to_send. Bound lower to mono 1 and upper to now + q->horizon. This protects against bad input, e.g., from BPF programs. Detect legacy BPF programs that program skb->tstamp without setting skb->tstamp_type. Here tstamp_type is zero (SKB_CLOCK_REALTIME), but the value will be unrealistic for realtime in the 21st century. Follow existing TIME_UPTIME_SEC_MAX as bound between mono and realtime. Signed-off-by: Willem de Bruijn <willemb@google.com> ---- Changes v1 -> v2 - replace Fixes tag with references inside the commit message Link: https://patch.msgid.link/20260604194221.3319080-3-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: ensure SCM_TXTIME delivery time is no older than system bootWillem de Bruijn
Limit input to sane values to avoid having to add tests later in the kernel hot path, e.g., in FQ. SCM_TXTIME timestamps are converted to signed ktime_t when assigned to skb->tstamp. Avoid having negative values overflow into large positive ones when again used as u64, e.g., in FQ time_to_send. For CLOCK_MONOTONIC, only allow positive values. For CLOCK_REALTIME and CLOCK_TAI, allow equivalent values, i.e., no older than the boot of the machine. skb->tstamp zero is a special case signaling feature off. This is not converted between clockids. Handle the special case where the realtime clock is set so small that real - mono is negative, however unlikely in practice. Ideally we would also set a sane upper bound, but that would require reading the clock, which is an expensive operation. Continue to defer that validation to users of the data. FQ already does this. Bound rather than return error on older timestamps. This is the existing policy e.g., in FQ. Signed-off-by: Willem de Bruijn <willemb@google.com> ---- Changes v1 -> v2 - remove spurious semicolon at end of switch - remove Fixes tag Link: https://patch.msgid.link/20260604194221.3319080-2-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08neighbour: remove obsolete EXPORT_SYMBOL()Eric Dumazet
IPv6 can't be a module anymore, we no longer need to export: - neigh_changeaddr - neigh_carrier_down - neigh_ifdown - neigh_connected_output - neigh_direct_output - neigh_table_init - neigh_table_clear Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260605073426.2922242-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08Merge tag 'batadv-next-pullrequest-20260605' of https://git.open-mesh.org/batadvJakub Kicinski
Simon Wunderlich says: ==================== This cleanup patchset includes the following patches, all by Sven Eckelmann: - tp_meter: initialize last_recv_time during init - convert cancellation of work items to disable helper - clean up wifi detection cache (3 patches) - clean up kernel-doc: corrections, reword, typos (6 patches) * tag 'batadv-next-pullrequest-20260605' of https://git.open-mesh.org/batadv: batman-adv: fix kernel-doc typos and grammar errors batman-adv: fix batadv_v_ogm_packet_recv error handling kernel-doc batman-adv: uapi: keep kernel-doc in struct member order batman-adv: bla: update stale kernel-doc batman-adv: tp_meter: update stale kernel-doc after refactoring batman-adv: correct batadv_wifi_* kernel-doc batman-adv: document cleanup of batadv_wifi_net_devices entries batman-adv: use GFP_KERNEL allocations for the wifi detection cache batman-adv: drop duplicated wifi_flags assignments batman-adv: convert cancellation of work items to disable helper batman-adv: tp_meter: initialize last_recv_time during init ==================== Link: https://patch.msgid.link/20260605072005.490368-1-sw@simonwunderlich.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08tcp: restrict SO_ATTACH_FILTER to priv usersEric Dumazet
This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Tamir Shahar <tamirthesis@gmail.com> Reported-by: Amit Klein <aksecurity@gmail.com> Cc: Willem de Bruijn <willemb@google.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Martin KaFai Lau <martin.lau@linux.dev> Cc: Eduard Zingerman <eddyz87@gmail.com> Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com> Cc: Song Liu <song@kernel.org> Cc: Yonghong Song <yonghong.song@linux.dev> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Fastabend <john.fastabend@gmail.com> Cc: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>