A user of my homebrew app hit a hard crash inside curl during a routine HTTPS request (the app never sets CURLOPT_CERTINFO). Atmosphere crash report, symbolized against my elf (curl statically linked from the current portlib):
Data Abort, Fault Address: 0x0
PC base64_encode (base64.c)
Curl_extract_certinfo
libnx_connect_step2 (libnx.c)
libnx_connect_common
Curl_ssl_connect_nonblocking
https_connecting -> multi_runsingle -> curl_multi_perform -> curl_easy_perform
Registers at the fault: X2=0xa4a (looks like the size argument), X4/X21=0x53 - base64_encode reading from a near-NULL source.
Looking at switch-curl.patch, in the hosversion >= 3.0.0 branch of the cert-info block, Curl_extract_certinfo(conn, 0, certdata, ...) runs for certificate index 0 on every TLS connection, because the if(!data->set.ssl.certinfo) break; only takes effect after index 0 is processed. So any quirk in what sslConnectionGetServerCertDetail returns for the first cert (NULL/short certdata with R_SUCCEEDED, or DER offsets that confuse the parser) crashes every app on that connection, whether or not it asked for cert info.
It is rare and transient (this one was against login.live.com; a relaunch connected fine, so likely dependent on which cert chain the CDN edge serves), which also makes it hard to reproduce on demand. Would it be reasonable to (a) guard certdata/certdata_size before calling Curl_extract_certinfo, and/or (b) skip the extraction entirely when data->set.ssl.certinfo is not set? Happy to provide the full crash report if useful.
A user of my homebrew app hit a hard crash inside curl during a routine HTTPS request (the app never sets CURLOPT_CERTINFO). Atmosphere crash report, symbolized against my elf (curl statically linked from the current portlib):
Registers at the fault: X2=0xa4a (looks like the size argument), X4/X21=0x53 - base64_encode reading from a near-NULL source.
Looking at switch-curl.patch, in the hosversion >= 3.0.0 branch of the cert-info block,
Curl_extract_certinfo(conn, 0, certdata, ...)runs for certificate index 0 on every TLS connection, because theif(!data->set.ssl.certinfo) break;only takes effect after index 0 is processed. So any quirk in whatsslConnectionGetServerCertDetailreturns for the first cert (NULL/shortcertdatawith R_SUCCEEDED, or DER offsets that confuse the parser) crashes every app on that connection, whether or not it asked for cert info.It is rare and transient (this one was against login.live.com; a relaunch connected fine, so likely dependent on which cert chain the CDN edge serves), which also makes it hard to reproduce on demand. Would it be reasonable to (a) guard
certdata/certdata_sizebefore calling Curl_extract_certinfo, and/or (b) skip the extraction entirely whendata->set.ssl.certinfois not set? Happy to provide the full crash report if useful.