From: Stefan Eissing <stefan@eissing.org>
Date: Wed, 23 Oct 2024 09:12:47 +0000 (+0200)
Subject: schannel: ignore error on recv beyond close notify
X-Git-Tag: curl-8_11_0~78
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f901ab84e611fec9e4989c2fdd99706ae1541d4b;p=thirdparty%2Fcurl.git

schannel: ignore error on recv beyond close notify

When receiving data, schannel does a recv from the lower filters, e.g.
the socket, *before* it decrypts and analyses the buffered data it
already has. When that buffer contains a close-notify, e.g. the end of
the TLS stream, any error on the previous receive from the socket are
not applicable to its return codes.

Example from #153345: a server sends a close notify and closes its
connection. The encrypted data, including the close notify is received.
Another receive on the sockets gets a CONNABORTED which curl reports as
CURLE_RECV_ERROR. Schannel analyses its bufferi, sees the close notify
and early returns to the caller. On this return, the error on the
attempted receive does not apply.

Closes #15381
---

diff --git a/lib/vtls/schannel.c b/lib/vtls/schannel.c
index 1fc3381a78..92186f6fe1 100644
--- a/lib/vtls/schannel.c
+++ b/lib/vtls/schannel.c
@@ -2319,6 +2319,11 @@ schannel_recv(struct Curl_cfilter *cf, struct Curl_easy *data,
         backend->recv_sspi_close_notify = TRUE;
         if(!backend->recv_connection_closed)
           backend->recv_connection_closed = TRUE;
+        /* We received the close notify just fine, any error we got
+         * from the lower filters afterwards (e.g. the socket), is not
+         * an error on the TLS data stream. That one ended here. */
+        if(*err == CURLE_RECV_ERROR)
+          *err = CURLE_OK;
         infof(data,
               "schannel: server close notification received (close_notify)");
         goto cleanup;