Segfault in curl_easy_perform #3548
I did this
Installed esniper on OpenBSD 6.4-current, which is using curl_easy_perform.
I expected the following
No error, but instead I got:
Program received signal SIGSEGV, Segmentation fault.
This is referenced in https://sourceforge.net/p/esniper/bugs/767
The executed action is a GET, but it segfaults if CURLOPT_POSTFIELDSIZE is not set to 0. To my knowledge, it should not even go there if the request is a GET.
curl 7.63.0 (x86_64-unknown-openbsd6.4) libcurl/7.63.0 LibreSSL/2.9.0 zlib/1.2.3 nghttp2/1.36.0
OpenBSD 6.4-current (also segfaults in OpenBSD 6.4)
If you set an option like
I agree that ideally libcurl should just ignore that pointer in this case, but I don't think that's a good reason for an application to keep a stale pointer set for curl. PR coming up.
referenced this issue
Feb 11, 2019
Just to clarify: The original code does not contain a POSTFIELDS !
This code crashes on BSD.
renaudallard then inserted
to solve those crashes (https://sourceforge.net/p/esniper/bugs/767/)
That's even more weird. curl allocates the entire handle with calloc so it is cleared from the beginning and thus the pointer is NULLed internally from the beginning.
So if you can provide a smaller libcurl example that can make this happen without setting POSTFIELDS then I'm very curious!
Maybe the reason for the segmentation fault is, that a previous call to the function 'httpRequest' uses the requerstType = POST. The pointer set by this previous call using CURLOPT_POSTFIELDS is only valid during is call and was been freed by the caller. But from my point of view an invalid pointer to CURLOPT_POSTFIELDS must not have any impact to calls using GET.
That's a very slippery slope and I will not make any guarantees that this is safe. #3549 tries to make it better, but passing in a stale pointer to curl is wrong and bad no matter which option combination you're using.