cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Use-after-free with libcurl+ares on windows?

From: Jason Pump <jason_at_healthdash.com>
Date: Thu, 04 Aug 2005 11:42:06 -0700

daniel-curl_at_haxx.se wrote:

> The problem is that ares_cancel() always unconditionally aborts all
pending callbacks and not just the single one we may want to cancel.

In that case, I guess this would just further hide the problem, not fix it.

Jason Pump wrote:

> Having been recently looking at code in this neighborhood, could you
> check conn->async.dns?
>
>> +#if defined(USE_ARES)
>
>
> if(!conn->async.dns) {
>
>> + ares_cancel(conn->data->state.areschannel);
>
>
> }
>
>> +#endif
>
>
>
> Jason
>
>
> Daniel Stenberg wrote:
>
>> On Thu, 4 Aug 2005, Harshal Pradhan wrote:
>>
>>> I really don't know much about the ares API and how ares is used in
>>> curl. On a random hunch, I tried the following
>>
>>
>>
>> ...
>>
>>> +#if defined(USE_ARES)
>>> + ares_cancel(conn->data->state.areschannel);
>>> +#endif
>>
>>
>>
>> ...
>>
>>> So, getting to the point .... I have lots of questions: Has anyone
>>> encountered such a problem earlier? Has there been any work on a
>>> similar issue in later versions of curl? Is my reasoning above sane?
>>> Does the my "random hunch" patch above make any sense at all?
>>
>>
>>
>> Thanks for this.
>>
>> I believe you are right on track, that there is a pending callback
>> that gets called after the connectdata struct has been freed and thus
>> it causes havoc. This is still so in the CVS version.
>>
>> However, this fix of yours blindly assumes that there is a pending
>> ares request for this connect data that we should cancel. When the
>> multi interface is used, the same ares 'channel' is used for name
>> resolves for all easy handles so this can most probably mistakenly
>> cancel a name resolve request for another handle if you have a bad day.
>>
>> I think we need to make sure that we only cancel actual callbacks for
>> this particular connect struct... But there's no really good API for
>> this in ares of today! I think we need to figure out and implement one.
>>
>> I'm open for (other) ideas on how this could be done.
>>
>
Received on 2005-08-04