The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=0b4f2ab0e91307bd1fa6e884b0fccef9d10d5a2d

commit 0b4f2ab0e91307bd1fa6e884b0fccef9d10d5a2d
Author:     Rick Macklem <[email protected]>
AuthorDate: 2022-05-15 18:51:56 +0000
Commit:     Rick Macklem <[email protected]>
CommitDate: 2022-05-15 18:51:56 +0000

    krpc: Fix NFS-over-TLS for KTLS1.3
    
    When NFS-over-TLS uses KTLS1.3, the client can receive
    post-handshake handshake records.  These records can be
    safely thown away, but are not handled correctly via the
    rpctls_ct_handlerecord() upcall to the daemon.
    
    Commit 373511338d95 changed soreceive_generic() so that it
    will only return ENXIO for Alert records when MSG_TLSAPPDATA
    is specified.  As such, the post-handshake handshake
    records will be returned to the krpc.
    
    This patch modifies the krpc so that it will throw
    these records away, which seems sufficient to make
    NFS-over-TLS work with KTLS1.3.  This change has
    no effect on the use of KTLS1.2, since it does not
    generate post-handshake handshake records.
    
    MFC after:      2 weeks
---
 sys/rpc/clnt_vc.c | 21 +++++++++------------
 sys/rpc/svc_vc.c  | 12 ++++++------
 2 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/sys/rpc/clnt_vc.c b/sys/rpc/clnt_vc.c
index f565de06f4bd..0c415d048141 100644
--- a/sys/rpc/clnt_vc.c
+++ b/sys/rpc/clnt_vc.c
@@ -944,7 +944,7 @@ clnt_vc_soupcall(struct socket *so, void *arg, int waitflag)
 {
        struct ct_data *ct = (struct ct_data *) arg;
        struct uio uio;
-       struct mbuf *m, *m2, **ctrlp;
+       struct mbuf *m, *m2;
        struct ct_request *cr;
        int error, rcvflag, foundreq;
        uint32_t xid_plus_direction[2], header;
@@ -992,13 +992,10 @@ clnt_vc_soupcall(struct socket *so, void *arg, int 
waitflag)
                m2 = m = NULL;
                rcvflag = MSG_DONTWAIT | MSG_SOCALLBCK;
                if (ct->ct_sslrefno != 0 && (ct->ct_rcvstate &
-                   RPCRCVSTATE_NORMAL) != 0) {
+                   RPCRCVSTATE_NORMAL) != 0)
                        rcvflag |= MSG_TLSAPPDATA;
-                       ctrlp = NULL;
-               } else
-                       ctrlp = &m2;
                SOCKBUF_UNLOCK(&so->so_rcv);
-               error = soreceive(so, NULL, &uio, &m, ctrlp, &rcvflag);
+               error = soreceive(so, NULL, &uio, &m, &m2, &rcvflag);
                SOCKBUF_LOCK(&so->so_rcv);
 
                if (error == EWOULDBLOCK) {
@@ -1023,8 +1020,8 @@ clnt_vc_soupcall(struct socket *so, void *arg, int 
waitflag)
                }
 
                /*
-                * A return of ENXIO indicates that there is a
-                * non-application data record at the head of the
+                * A return of ENXIO indicates that there is an
+                * alert record at the head of the
                 * socket's receive queue, for TLS connections.
                 * This record needs to be handled in userland
                 * via an SSL_read() call, so do an upcall to the daemon.
@@ -1051,10 +1048,10 @@ clnt_vc_soupcall(struct socket *so, void *arg, int 
waitflag)
                            cmsg->cmsg_len == CMSG_LEN(sizeof(tgr))) {
                                memcpy(&tgr, CMSG_DATA(cmsg), sizeof(tgr));
                                /*
-                                * This should have been handled by
-                                * setting RPCRCVSTATE_UPCALLNEEDED in
-                                * ct_rcvstate but if not, all we can do
-                                * is toss it away.
+                                * TLS_RLTYPE_ALERT records should be handled
+                                * since soreceive() would have returned
+                                * ENXIO.  Just throw any other
+                                * non-TLS_RLTYPE_APP records away.
                                 */
                                if (tgr.tls_type != TLS_RLTYPE_APP) {
                                        m_freem(m);
diff --git a/sys/rpc/svc_vc.c b/sys/rpc/svc_vc.c
index f0e0ee5d4d62..43d14c702d4e 100644
--- a/sys/rpc/svc_vc.c
+++ b/sys/rpc/svc_vc.c
@@ -804,8 +804,8 @@ tryagain:
                }
 
                /*
-                * A return of ENXIO indicates that there is a
-                * non-application data record at the head of the
+                * A return of ENXIO indicates that there is an
+                * alert record at the head of the
                 * socket's receive queue, for TLS connections.
                 * This record needs to be handled in userland
                 * via an SSL_read() call, so do an upcall to the daemon.
@@ -863,10 +863,10 @@ tryagain:
                            cmsg->cmsg_len == CMSG_LEN(sizeof(tgr))) {
                                memcpy(&tgr, CMSG_DATA(cmsg), sizeof(tgr));
                                /*
-                                * This should have been handled by
-                                * the rpctls_svc_handlerecord()
-                                * upcall.  If not, all we can do is
-                                * toss it away.
+                                * TLS_RLTYPE_ALERT records should be handled
+                                * since soreceive() would have returned
+                                * ENXIO.  Just throw any other
+                                * non-TLS_RLTYPE_APP records away.
                                 */
                                if (tgr.tls_type != TLS_RLTYPE_APP) {
                                        m_freem(m);

Reply via email to