romenskiy2012/curl
1
0
Fork 0
mirror of https://github.com/curl/curl.git synced 2026-06-16 10:55:38 +03:00
Code Issues Projects Releases Packages Wiki Activity

multi: fix bad splay management

Browse source 
The splay tree is a tree where each easy handle can be added *once*. The
expire time for that node is the closest expire time for that easy
handle.

Easy handles can however have more expire times queued up, so when the
node is removed from the splay tree because it is the next in line to
take care of, we must check if there is another expire time in the queue
and then add the node back into the splay.

Failing to do the later part, the calling of add_next_timeout after
Curl_splaygetbest, would leave the state.expiretime on the previous time
stamp, which when could make the next call to Curl_splaygetbest use the
wrong time stamp and get a wrong node out, causing trouble.

Reported-by: letshack9707 on hackerone
Closes #18201
This commit is contained in:
Daniel Stenberg 2025-08-06 09:03:31 +02:00
parent 6cebd35b4c
commit 019991c25e
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
1 changed files with 1 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

3
lib/multi.c
View file

@ -2793,16 +2793,15 @@ CURLMcode curl_multi_perform(CURLM *m, int *running_handles)
if(t) {
/* the removed may have another timeout in queue */
struct Curl_easy *data = Curl_splayget(t);
(void)add_next_timeout(now, multi, data);
if(data->mstate == MSTATE_PENDING) {
bool stream_unused;
CURLcode result_unused;
if(multi_handle_timeout(data, &now, &stream_unused, &result_unused)) {
infof(data, "PENDING handle timeout");
move_pending_to_connect(multi, data);
continue;
}
}
(void)add_next_timeout(now, multi, Curl_splayget(t));
}
} while(t);