kernel/git/next/linux-next.git/net/sunrpc, branch master

Merge branch 'headers' of git://git.infradead.org/users/willy/pagecache.git

2026-09-11T15:17:01+00:00

# Conflicts: # net/ceph/osd_client.c

SUNRPC: Fold xs_sock_process_cmsg() into its only caller

2026-09-06T23:44:53+00:00

xs_sock_process_cmsg() switches on the TLS record type, and every arm but TLS_RECORD_TYPE_ALERT returns the -EAGAIN its caller passed in. The DATA arm clears MSG_EOR in the caller's msghdr, but xs_sock_recvmsg() has already cleared that flag before the call. Deriving the record type a second time inside the helper also fires trace_tls_contenttype() twice for every alert. Move the alert handling into xs_sock_recv_cmsg() and delete the helper. Every other record type still returns -EAGAIN. The DATA arm's account of MSG_EOR moves to xs_sock_recvmsg(), where the flag is cleared. Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-7-62d9a631c880@kernel.org Signed-off-by: Chuck Lever

SUNRPC: Treat every client-side TLS error alert as fatal

2026-09-06T23:44:53+00:00

xs_sock_process_cmsg() decides whether an alert ends the session by reading the alert's level octet. RFC 8446 Section 6 retired that field. The severity is implicit in the description, and a receiver treats every alert listed in Section 6.2 as an error alert "regardless of the AlertLevel in the message". A peer that aborts with unexpected_message but leaves the legacy octet set to warning makes the client return -EAGAIN. xs_stream_data_receive() wakes no pending task for that error, so RPC Calls queued on a dead TLS session wait for their timeouts to expire. Decide from the alert description instead. close_notify and user_canceled are the closure alerts (RFC 8446 Section 6.1). Every other description ends the session, including one this kernel does not recognize. Fixes: 39067dda1d86 ("SUNRPC: Use new helpers to handle TLS Alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-6-62d9a631c880@kernel.org Signed-off-by: Chuck Lever

SUNRPC: Reject a client-side TLS alert record that is not two octets

2026-09-06T23:44:53+00:00

tls_alert_recv() reads two octets from the kvec it is handed and does not check the length (net/handshake/alert.c). xs_sock_process_cmsg() calls it for any alert record, and the alert[] buffer that xs_sock_recv_cmsg() supplies carries no initializer. A one-octet alert body leaves the description read from uninitialized stack and reported through trace_tls_alert_recv(). The peer controls that length. Neither tls_rx_msg_size() nor tls_rx_one_record() enforces the two-octet Alert payload. A TLS 1.3 record carrying only the inner content-type octet decrypts to a zero-length payload. RFC 8446 Section 5.1 requires a record with an Alert type to carry exactly one message, so any other length is malformed. RFC 9289 Section 5 bars RPC-with-TLS from negotiating a version below TLS 1.3, so no other alert framing applies. Require exactly two octets before parsing and return -EACCES otherwise. xs_stream_data_receive() already treats -EACCES as a fatal alert and reports it to the pending tasks. Gate the path on a control message rather than a positive count so that a zero-length record reaches the check. Fixes: cc5d59081fa2 ("sunrpc: fix client side handling of tls alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-5-62d9a631c880@kernel.org Signed-off-by: Chuck Lever

SUNRPC: Resume receiving after a TLS control record

2026-09-06T23:44:53+00:00

A TLS control record delivers no payload to the RPC layer. svc_tcp_recvfrom() clears XPT_DATA before the receive, and svc_tcp_sock_recv_cmsg() returns -EAGAIN for the record it consumed. Nothing marks the transport ready again. kTLS raises data_ready for arriving TCP segments, not for records it has already decrypted. An RPC Call queued behind an alert or a KeyUpdate waits until the client sends more. The client blocks until its RPC timeout expires. The receive takes only the first two octets of the record. kTLS holds the remainder on its receive list, where each later receive takes two octets more. Drain a record that is not an alert, then mark the transport ready once a control record has been consumed. Fixes: 5e052dda121e ("SUNRPC: Recognize control messages in server-side TCP socket code") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-4-62d9a631c880@kernel.org Signed-off-by: Chuck Lever

SUNRPC: Treat every TLS error alert as fatal

2026-09-06T23:44:53+00:00

svc_tcp_sock_process_cmsg() decides whether an alert ends the session by reading the alert's level octet. RFC 8446 Section 6 retired that field. The severity is implicit in the description, and a receiver treats every alert listed in Section 6.2 as an error alert "regardless of the AlertLevel in the message". A peer that aborts with unexpected_message but leaves the legacy octet set to warning makes the server return -EAGAIN. svc_tcp_recvfrom() then leaves a dead TLS session attached to an open transport. NFSD keeps polling it. Decide from the alert description instead. close_notify and user_canceled are the closure alerts (RFC 8446 Section 6.1). Every other description ends the session, including one this kernel does not recognize. Fixes: 39067dda1d86 ("SUNRPC: Use new helpers to handle TLS Alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-3-62d9a631c880@kernel.org Signed-off-by: Chuck Lever

SUNRPC: Reject a TLS alert record that is not two octets

2026-09-06T23:44:53+00:00

tls_alert_recv() reads two octets from the kvec it is handed and does not check the length (net/handshake/alert.c). svc_tcp_sock_recv_cmsg() calls it for any positive receive, and the alert[] buffer it supplies carries no initializer. A one-octet alert body leaves the description read from uninitialized stack and reported through trace_tls_alert_recv(). The peer controls that length. Neither tls_rx_msg_size() nor tls_rx_one_record() enforces the two-octet Alert payload. A TLS 1.3 record carrying only the inner content-type octet decrypts to a zero-length payload. RFC 8446 Section 5.1 requires a record with an Alert type to carry exactly one message, so any other length is malformed. Require exactly two octets before parsing and return -EBADMSG otherwise. That closes the transport rather than acting on a partly uninitialized alert. Gate the path on a control message rather than a positive count so that a zero-length record reaches the check. Fixes: bee47cb026e7 ("sunrpc: fix handling of server side tls alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-2-62d9a631c880@kernel.org Signed-off-by: Chuck Lever

SUNRPC: Do not credit control-record octets to the RPC stream

2026-09-06T23:44:53+00:00

svc_tcp_sock_recv_cmsg() receives up to two octets into a local buffer, and returns that count for any record type other than TLS_RECORD_TYPE_ALERT. Nothing reached the caller's buffer, but svc_tcp_read_marker() adds the count to sk_tcplen and svc_tcp_read_msg()'s caller adds it to sk_datalen. The RPC stream advances over octets it never received. The fragment marker is assembled from stale sk_marker octets. The message body comes from pages nothing wrote. A conforming client reaches this. RFC 8446 Section 4.6.3 lets either peer send KeyUpdate once it has sent its Finished, and svcsock has no rekey path. kTLS leaves the partially consumed record on ctx->rx_list, so the body drains two octets per svc_tcp_recvfrom() call. Each pair is credited the same way. Return -EAGAIN for a record that is not an alert. That is what svc_tcp_sock_process_cmsg()'s default arm returned before the receive moved into a local buffer. Fixes: bee47cb026e7 ("sunrpc: fix handling of server side tls alerts") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260808-svcsock-cmsg-fixes-v3-1-62d9a631c880@kernel.org Signed-off-by: Chuck Lever

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

Merge tag 'nfs-for-7.3-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs

2026-08-26T22:09:21+00:00

Pull NFS client updates from Trond Myklebust: "Highlights include: Stable fixes: - Use-after-free fixes for the sunrpc client code - Delegation hash table leak - NULL dereference on lockowner allocation failure - Fix a handshake completion race in the TLS code - Fix an error sign checking issue when deciding whether the pNFS layout is still in use, or can be returned - Fix a layout segment leak in pnfs_layout_process() Other bugfixes: - Fix a missing NULL check in the rpcbind client - annotate shared socket callbacks with READ_ONCE/WRITE_ONCE - nfs_inode_set_delegation() error paths should return the delegation - Use clear_and_wake_up_bit() in nfs_clear_invalid_mapping() and the pNFS code. - Fix the nfs4_alloc_client() error paths to free the IDR allocation - fix folio dereference before NULL check in nfs_inode_remove_request() - Fix delayed delegation return - Fix another state manager race with umount - Fix device leaks on parse failure - Avoid cancelling in-flight I/O during a layout recall if the server doesn't require it - flexfiles: report cancelled I/O as a layout error - flexfiles: fix NULL dereference for NFSv4.0 data servers - Fix incorrect argument passed to nfs4_delete_lease() - Fix several symlink issues resulting from nfs_atomic_open_v23() - Fix an uninitialised variable issue in the NFSv4.1 callback code - fix LAYOUTSTATS send buffer exhaustion Features and cleanups: - NFSv4.2: Allow the server to specify that file data may not be cached - localio: optimise I/O submission when when not doing memory reclaim - localio: Remove duplicate wait code in nfs_local_commit - flexfiles: support loosely coupled NFSv4.x data servers - pNFS: key the data server cache on the NFS version" * tag 'nfs-for-7.3-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: (33 commits) NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path NFSv4/pnfs: key the data server cache on the NFS version NFSv4.2: fix LAYOUTSTATS send buffer exhaustion pNFS: Fix EBUSY check in pnfs_layout_need_return NFSv4.1: zero referring call lists before decoding nfs: fix ENXIO on O_CREAT open of existing symlink over NFSv3 SUNRPC: wait for in-flight client TLS handshake callback NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in nfs4_add_lease() lockd: fix NULL dereference on lockowner allocation failure NFS: fix delegation_hash_table leak when nfs4_server_common_setup() fails NFSv4/flexfiles: support loosely coupled data servers NFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers NFSv4: pin the superblock for active state owners sunrpc: fix use-after-free in __rpc_clnt_handle_event and __rpc_clnt_remove_pipedir NFS/localio: issue commit inline when not in a memory-reclaim context NFS/localio: remove dead FLUSH_SYNC handling from nfs_local_commit NFS/localio: issue IO inline when not in a memory-reclaim context NFS: Fix delayed delegation return list handling NFS: Verify symlink inode before caching target NFS: fix folio dereference before NULL check in nfs_inode_remove_request() ...