]> git.ipfire.org Git - thirdparty/curl.git/commitdiff
schannel: ignore error on recv beyond close notify
authorStefan Eissing <stefan@eissing.org>
Wed, 23 Oct 2024 09:12:47 +0000 (11:12 +0200)
committerDaniel Stenberg <daniel@haxx.se>
Thu, 24 Oct 2024 08:06:40 +0000 (10:06 +0200)
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

lib/vtls/schannel.c

index 1fc3381a78ef0cda4c0ec1a3c909209938465602..92186f6fe1cafc931bdcbe55ea2fdf5d03905188 100644 (file)
@@ -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;