- Dillo-dev - lists.mailman3.com

Re: Patches for two use-after-free bugs

by Rodrigo Arias

Hi Magnus, On Sat, Jan 24, 2026 at 11:13:25AM -0800, Nopey Nope wrote: >Hello! > >Find attached two patches, which each fix a use-after-free bug. > >I've also attached a crashing html document for each, but please be >aware that these reproducer documents link urls from external web >servers. >The reproducers crash reliably on my x86_64 Void Linux laptop, but >I've not tested them elsewhere. I've also attached a crash log with >asan reporting of each. > >Thank you >-Magnus L > >p.s. I've also opened github PR 449 with these same changes, but >figured I should send the patches via email as well-- if only for >practice :) Thanks a lot for the patches and reproducers! I saw the PR but I only had time to look at the "Fix use-after-free in openssl cert popup" commit which seems good. We are moving away from GitHub so it would be nice to send future patches here (or a link to a git repo/branch to fetch with git). It would help to describe what is the condition that triggers the UAF in the Http_server patch and why the change helps, so that it is easier to review. Perhaps it would be a good idea to put that information it in the commit summary of both patches so we can see it via git blame. Best, Rodrigo.

Jan. 24, 2026

Patches for two use-after-free bugs

by Nopey Nope

Hello! Find attached two patches, which each fix a use-after-free bug. I've also attached a crashing html document for each, but please be aware that these reproducer documents link urls from external web servers. The reproducers crash reliably on my x86_64 Void Linux laptop, but I've not tested them elsewhere. I've also attached a crash log with asan reporting of each. Thank you -Magnus L p.s. I've also opened github PR 449 with these same changes, but figured I should send the patches via email as well-- if only for practice :)

Jan. 24, 2026

Re: Segfault while running SSL Labs CurveBall test

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > This patch should get rid of the segfault, but I need to take a closer > look and see if we are handling it well for LibreSSL, as they expose > headers from version 2 from OpenSSL. > > ---8<--- > diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c > index 3345a0dc..d1df2315 100644 > --- a/src/IO/tls_openssl.c > +++ b/src/IO/tls_openssl.c > @@ -471,14 +471,12 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) > char buf[buflen]; > int rc, i, n = sk_X509_num(sk); > X509 *cert = NULL; > - EVP_PKEY *public_key; > int key_type, key_bits; > const char *type_str; > BIO *b; > > for (i = 0; i < n; i++) { > cert = sk_X509_value(sk, i); > - public_key = X509_get_pubkey(cert); > > /* We are trying to find a way to get the hash function used > * with a certificate. This way, which is not very pleasant, puts > @@ -521,6 +519,10 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) > if (print_chain) > MSG("%s ", buf); > > + EVP_PKEY *public_key = X509_get_pubkey(cert); > + if (public_key == NULL) > + continue; > + > #if OPENSSL_VERSION_NUMBER < 0x30000000L > key_type = EVP_PKEY_type(EVP_PKEY_id(public_key)); > #else > ---8<--- Thanks! Now the segfault is gone: Nav_open_url: new url='https://www.ssllabs.com:10446/' Dns_server [0]: www.ssllabs.com is 69.67.183.100 Connecting to 69.67.183.100:10446 www.ssllabs.com:10446: TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384 ecdsa-with-SHA256 384-bit EC: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs CurveBall Leaf/CN=www.ssllabs.com ecdsa-with-SHA256 root: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs/CN=SSLLabs CurveBall CA SSL_read() failed: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib SSL_read() failed: error:10FFF07F:elliptic curve routines:CRYPTO_internal:pkparameters2group failure SSL_read() failed: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib SSL_read() failed: error:10FFF08E:elliptic curve routines:CRYPTO_internal:decode error SSL_read() failed: error:0BFFF07D:x509 certificate routines:CRYPTO_internal:public key decode error Tls_close_by_key: Avoiding SSL shutdown for: https://www.ssllabs.com:10446/ Premature close for https://www.ssllabs.com:10446/ Regards, Alex

Jan. 16, 2026

Re: Avoid ctype(3) abuses

by Leonardo Taccari

Rodrigo Arias writes: > Hi, > > >Updated patches modified as required attached in this email. > > > >Now ctype(3) usage is only via d*() helper ctype(3) functions. > > Thanks!, it looks good. I will test it a bit and merge it if nothing > breaks. I will also add src/commit.h to .gitignore so we prevent this: > > >diff --git a/src/commit.h b/src/commit.h > >new file mode 100644 > >index 00000000..7c4f940d > >--- /dev/null > >+++ b/src/commit.h > >@@ -0,0 +1 @@ > >+#define GIT_COMMIT "v3.2.0-143-gabad1053-dirty" > [...] Whoops, sorry for that extra hunk! I was focused on double-checking the ctype(3) -> d*() helper transformations that I have completely missed that. :\ Thank you very much Rodrigo!

Jan. 16, 2026

Re: Avoid ctype(3) abuses

by Rodrigo Arias

>Thanks!, it looks good. I will test it a bit and merge it if nothing >breaks. I will also add src/commit.h to .gitignore so we prevent this: Merged.

Jan. 15, 2026

Re: Avoid ctype(3) abuses

by Rodrigo Arias

Hi, >Updated patches modified as required attached in this email. > >Now ctype(3) usage is only via d*() helper ctype(3) functions. Thanks!, it looks good. I will test it a bit and merge it if nothing breaks. I will also add src/commit.h to .gitignore so we prevent this: >diff --git a/src/commit.h b/src/commit.h >new file mode 100644 >index 00000000..7c4f940d >--- /dev/null >+++ b/src/commit.h >@@ -0,0 +1 @@ >+#define GIT_COMMIT "v3.2.0-143-gabad1053-dirty" Best, Rodrigo.

Jan. 15, 2026

Segfault while running SSL Labs CurveBall test

by a1ex＠dismail.de

Hi, I was running some tests from ssllabs.com and ran into a segfault. I used the "CurveBall" manual test link from this page: https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html Which points to: https://www.ssllabs.com:10446/ Nav_open_url: new url='https://www.ssllabs.com:10446/' Connecting to 69.67.183.100:10446 www.ssllabs.com:10446: TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384 ecdsa-with-SHA256 384-bit EC: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs CurveBall Leaf/CN=www.ssllabs.com ecdsa-with-SHA256 Program received signal SIGSEGV, Segmentation fault. _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 793 return pkey->type; (gdb) bt #0 _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 #1 0x000001f9ee7da2b0 in Tls_check_cert_strength (ssl=<optimized out>, srv=<optimized out>, choice=0x6faff21f66f8) at tls_openssl.c:526 #2 0x000001f9ee7d8fd3 in Tls_examine_certificate (ssl=0x1fca8ddac80, srv=0x1fc1b4056a0) at tls_openssl.c:865 #3 Tls_connect (fd=7, connkey=4) at tls_openssl.c:1208 #4 0x000001fce9a7a7f0 in fl_wait(double) () from /usr/local/lib/libfltk.so.9.0 #5 0x000001fce9a0777f in Fl::wait(double) () from /usr/local/lib/libfltk.so.9.0 #6 0x000001fce9a079a1 in Fl::wait() () from /usr/local/lib/libfltk.so.9.0 #7 0x000001f9ee77e774 in main (argc=1, argv=0x6faff21f6a48) at dillo.cc:621 When I try to open it with curl, this is the result: curl: (35) TLS connect error: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib This is on OpenBSD, using LibreSSL. I did a curl test on a Linux box and didn't get that error, so it may be LibreSSL specific. Happy to do further testing if you have any ideas. Regards, Alex

Jan. 15, 2026

Re: Segfault while running SSL Labs CurveBall test

by Rodrigo Arias

Hi, On Thu, Jan 15, 2026 at 09:44:50PM +0000, a1ex(a)dismail.de wrote: >Hi, > >I was running some tests from ssllabs.com and ran into a segfault. > >I used the "CurveBall" manual test link from this page: >https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html > >Which points to: https://www.ssllabs.com:10446/ > >Nav_open_url: new url='https://www.ssllabs.com:10446/' >Connecting to 69.67.183.100:10446 >www.ssllabs.com:10446: TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384 >ecdsa-with-SHA256 384-bit EC: /C=US/ST=California/L=Foster City/O=Qualys, Inc./OU=SSLLabs CurveBall Leaf/CN=www.ssllabs.com >ecdsa-with-SHA256 >Program received signal SIGSEGV, Segmentation fault. >_lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 >793 return pkey->type; >(gdb) bt >#0 _lcry_EVP_PKEY_id (pkey=0x0) at /usr/src/lib/libcrypto/evp/p_lib.c:793 >#1 0x000001f9ee7da2b0 in Tls_check_cert_strength (ssl=<optimized out>, > srv=<optimized out>, choice=0x6faff21f66f8) at tls_openssl.c:526 >#2 0x000001f9ee7d8fd3 in Tls_examine_certificate (ssl=0x1fca8ddac80, srv=0x1fc1b4056a0) > at tls_openssl.c:865 >#3 Tls_connect (fd=7, connkey=4) at tls_openssl.c:1208 >#4 0x000001fce9a7a7f0 in fl_wait(double) () from /usr/local/lib/libfltk.so.9.0 >#5 0x000001fce9a0777f in Fl::wait(double) () from /usr/local/lib/libfltk.so.9.0 >#6 0x000001fce9a079a1 in Fl::wait() () from /usr/local/lib/libfltk.so.9.0 >#7 0x000001f9ee77e774 in main (argc=1, argv=0x6faff21f6a48) at dillo.cc:621 > >When I try to open it with curl, this is the result: >curl: (35) TLS connect error: error:10FFF010:elliptic curve routines:CRYPTO_internal:EC lib > >This is on OpenBSD, using LibreSSL. > >I did a curl test on a Linux box and didn't get that error, so it may >be LibreSSL specific. Thanks, I can reproduce it on Linux with LibreSSL 4.2.1 and ASan enabled: ==1123582==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f31c4d0b3a4 bp 0x7ffc3dc12070 sp 0x7ffc3dc10eb8 T0) ==1123582==The signal is caused by a READ memory access. ==1123582==Hint: address points to the zero page. #0 0x7f31c4d0b3a4 in EVP_PKEY_id (/usr/lib/libressl/libcrypto.so.57+0xae3a4) (BuildId: 15f17022dc7dbd5298bf906f2ef4e53d12c52015) #1 0x55c7110c71cf in Tls_check_cert_strength ../../../src/IO/tls_openssl.c:525 #2 0x55c7110c87d1 in Tls_examine_certificate ../../../src/IO/tls_openssl.c:864 #3 0x55c7110ca507 in Tls_connect ../../../src/IO/tls_openssl.c:1207 #4 0x55c7110ca6e0 in Tls_connect_cb ../../../src/IO/tls_openssl.c:1239 #5 0x7f31c4ab06ec in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa66ec) (BuildId: 35d154011fe6e73efbad51f873a8c4e488e91451) #6 0x7f31c4a4e0fd in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x440fd) (BuildId: 35d154011fe6e73efbad51f873a8c4e488e91451) #7 0x7f31c4a4e232 in Fl::wait() (/usr/lib/libfltk.so.1.3+0x44232) (BuildId: 35d154011fe6e73efbad51f873a8c4e488e91451) #8 0x55c710fd9009 in main ../../src/dillo.cc:621 #9 0x7f31c4227634 (/usr/lib/libc.so.6+0x27634) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d) #10 0x7f31c42276e8 in __libc_start_main (/usr/lib/libc.so.6+0x276e8) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d) #11 0x55c710fd5f74 in _start (/home/ram/dev/dillo/git/build-asan/src/dillo+0x12f74) (BuildId: 850e3f88a121a05841fca5389243b0482d69b6b0) This patch should get rid of the segfault, but I need to take a closer look and see if we are handling it well for LibreSSL, as they expose headers from version 2 from OpenSSL. ---8<--- diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c index 3345a0dc..d1df2315 100644 --- a/src/IO/tls_openssl.c +++ b/src/IO/tls_openssl.c @@ -471,14 +471,12 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) char buf[buflen]; int rc, i, n = sk_X509_num(sk); X509 *cert = NULL; - EVP_PKEY *public_key; int key_type, key_bits; const char *type_str; BIO *b; for (i = 0; i < n; i++) { cert = sk_X509_value(sk, i); - public_key = X509_get_pubkey(cert); /* We are trying to find a way to get the hash function used * with a certificate. This way, which is not very pleasant, puts @@ -521,6 +519,10 @@ static bool_t Tls_check_cert_strength(SSL *ssl, Server_t *srv, int *choice) if (print_chain) MSG("%s ", buf); + EVP_PKEY *public_key = X509_get_pubkey(cert); + if (public_key == NULL) + continue; + #if OPENSSL_VERSION_NUMBER < 0x30000000L key_type = EVP_PKEY_type(EVP_PKEY_id(public_key)); #else ---8<--- Best, Rodrigo.

Jan. 15, 2026

Re: Avoid ctype(3) abuses

by Leonardo Taccari

Leonardo Taccari writes: > [...] > Good idea! > > I will then add possible missing d*() helper ctype(3) functions and > adapt all direct ctype(3) users to switch to such d*() helper > functions. > > I hope to be able to share possible patches for that in 48 hours or so! > [...] Updated patches modified as required attached in this email. Now ctype(3) usage is only via d*() helper ctype(3) functions. Thanks!

Jan. 15, 2026

Re: Segfault on form submit / CSS display:none

by Rodrigo Arias

Hi, On Wed, Jan 14, 2026 at 11:40:34AM +0100, Thomas Rudolph wrote: > Hi, > > the following html code causes Dillo to segfault in the latest git > versions when clicking the button. I stripped the html down to the > problem: > > <form> > > <span style="display:none;"> > <input type="checkbox" name="x"> > </span> > > <input type=submit name="submit" value="Crash"> > > </form> > > This is reproducible on my Raspberry Pi OS (Debian 13) machine as well > as on my laptop (Debian 13). > > Removing either "display:none;", or the name attribute of the input, > or disabling embedded CSS results in Dillo not crashing. > Input type text crashes as well as checkbox. > Older versions of Dillo such as the 3.2.0 release do not crash on this > code, too. Thanks for the report. Yes, is a known problem: https://bug.dillo-browser.org/506/ The fix is in progress. As a workaround you can disable CSS for that page to submit the form or use 3.2.0. > Thanks for resurrecting this awesome browser. It has become my default > browser for 60-70 percent of the web. Glad to read that :) Best, Rodrigo.

Jan. 15, 2026