curl / Mailing Lists / curl-library / Single Mail

Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: SIGSEGV in curl-8.6.0/lib/http2.c:288 (curl_multi_perform->extract_if_dead->http2_data_done)

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Aleksander Mazur via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 26 Mar 2024 16:57:23 +0100

Dnia 2024-03-25, o godz. 22:33:13 Jeffrey Walton <noloader_at_gmail.com>
napisał(a):

> You have to build your application and cURL with -O0 or -O1. Valgrind
> becomes inaccurate at -O2 and above, and sometimes incorrectly reports
> uninitialized memory. Also see
> <https://valgrind.org/docs/manual/quick-start.html>.

Yes, I had built both my application and cURL with -O0.

BTW. the error reported by Valgrind is not about uninitialized memory, but
out-of-bounds memory access due to using wrong union member:
1. allocated sizeof(struct SMTP) and put into SingleRequest.p.smtp;
2. cast to (struct HTTP *) and trying to access h2_ctx.

Anyway, I reproduced the problem under gdb (segfault):

#0 0x00007ffff7e4a6ba in http2_data_done (cf=0x794698, data=0x490878,
premature=true) at http2.c:288 #1 0x00007ffff7e4f1e9 in cf_h2_cntrl
(cf=0x794698, data=0x490878, event=2, arg1=0, arg2=0x0) at http2.c:2513 #2
0x00007ffff7e2ad14 in Curl_conn_cf_cntrl (cf=0x794698, data=0x490878,
ignore_result=true, event=2, arg1=0, arg2=0x0) at cfilters.c:501 #3
0x00007ffff7e2af39 in cf_cntrl_all (conn=0x79bf28, data=0x490878,
ignore_result=true, event=2, arg1=0, arg2=0x0) at cfilters.c:551 #4
0x00007ffff7e2afd0 in Curl_conn_ev_data_detach (conn=0x79bf28, data=0x490878)
at cfilters.c:568 #5 0x00007ffff7e5ad86 in Curl_detach_connection
(data=0x490878) at multi.c:973 #6 0x00007ffff7e79dc4 in extract_if_dead
(conn=0x79bf28, data=0x490878) at url.c:828 #7 0x00007ffff7e79e1f in
call_extract_if_dead (data=0x490878, conn=0x79bf28, param=0x7fffffffda80) at
url.c:854 #8 0x00007ffff7e2c72d in Curl_conncache_foreach (data=0x490878,
connc=0x464288, param=0x7fffffffda80, func=0x7ffff7e79df0
<call_extract_if_dead>) at conncache.c:332 #9 0x00007ffff7e7a00a in
prune_dead_connections (data=0x490878) at url.c:883 #10 0x00007ffff7e7e72d in
create_conn (data=0x490878, in_connect=0x7fffffffdb60, async=0x7fffffffdbce) at
url.c:3635 #11 0x00007ffff7e7ed0e in Curl_connect (data=0x490878,
asyncp=0x7fffffffdbce, protocol_done=0x7fffffffdbcf) at url.c:3873 #12
0x00007ffff7e5cb9f in multi_runsingle (multi=0x464178, nowp=0x7fffffffdcf0,
data=0x490878) at multi.c:2002 #13 0x00007ffff7e5e5b8 in curl_multi_perform
(multi=0x464178, running_handles=0x7fffffffdd54) at multi.c:2780 #14
0x000000000041b6d3 in main (argc=2, argv=0x7fffffffde98) at main.c:239 (gdb) fr
6 #6 0x00007ffff7e79dc4 in extract_if_dead (conn=0x79bf28, data=0x490878) at
url.c:828 828 Curl_detach_connection(data); (gdb) p data.state.url
$33 = 0x49f9b8 "smtps://poczta.interia.pl/" (gdb) print conn.handler $34 =
(const struct Curl_handler *) 0x7ffff7eca0e0 <Curl_handler_https> (gdb) print
conn.host.name $35 = 0x61ced8 "securetoken.googleapis.com"

extract_if_dead() is called with HTTPS connection and SMTPS transfer.
How it is supposed to handle this situation?
It seems that extract_if_dead() briefly attaches and detaches them.
Detaching includes calling Curl_conn_ev_data_detach() what involves passing
this SMTPS transfer to all HTTPS-specific connection filters.
This way http2_data_done() gets called with a transfer initialized by
smtp_init() so libcurl crashes trying to evaluate H2_STREAM_CTX(data) on it.

-- 
Aleksander Mazur
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2024-03-26

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]