Eygene Ryabinkin fixed a use-after-free issue with HTTP transfers with the

multi interface

1 files changed, 20 insertions, 0 deletions

diff --git a/CHANGES b/CHANGES
index 129dbdc34..7c473de95 100644
--- a/CHANGES
+++ b/CHANGES
@@ -7,6 +7,26 @@
                                   Changelog
 
 Daniel (10 March 2007)
+- Eygene Ryabinkin:
+
+  The problem is the following: when we're calling Curl_done and it decides to
+  keep the connection opened ('left intact'), then the caller is not notified
+  that the connection was done via the NULLifying of the pointer, so some easy
+  handle is keeping the pointer to this connection.
+
+  Later ConnectionExists can select such connection for reuse even if we're
+  not pipelining: pipeLen is zero, so the (pipeLen > 0 && !canPipeline) is
+  false and we can reuse this connection for another easy handle. But thus the
+  connection will be shared between two easy handles if the handle that wants
+  to take the ownership is not the same as was not notified of the connection
+  was done in Curl_done. And when some of these easy handles will get their
+  connection really freed the another one will still keep the pointer.
+
+  My fix was rather trivial: I just added the NULLification to the 'else'
+  branch in the Curl_done. My tests with Git and ElectricFence showed no
+  problems both for HTTP pulling and cloning. Repository size is about 250 Mb,
+  so it was a considerable amount of Curl's work.
+
 - Bryan Henderson introduces two things:
   1) the progress callback gets called more frequently (at times)
   2) libcurl *might* call the callback when it receives a signal: