- Dillo-dev - lists.mailman3.com

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

Segfault on form submit / CSS display:none

by Thomas Rudolph

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 resurrecting this awesome browser. It has become my default browser for 60-70 percent of the web. All the best, Thomas

Jan. 14, 2026

Re: Avoid ctype(3) abuses

by Leonardo Taccari

Hello Rodrigo, Rodrigo Arias writes: > Hi, > > On Mon, Jan 12, 2026 at 11:05:17AM +0100, Leonardo Taccari wrote: > >Hello! > > > >Most ctype(3) functions usage abuses an undefined behavior of passing > >values outside integers outside EOF or the range representable as > >unsigned char. > > > >On NetBSD 11 and newer such incorrect behaviors crashes applications > >violating that and due that Dillo easily crash by just visiting, e.g. > ><https://www.NetBSD.org/>. > > > >For possible further information please give a look to > ><https://man.NetBSD.org/ctype.3#CAVEATS>. > > Interesting! > > >I have grep-ed all such uses and added the relevant cast to uchar_t > >similar to other ctype(3) calls already present and in that way I can > >also confirm that Dillo no longer crashes. > > Thanks for the patch and tests. > > We have wrappers that do just that for isspace() and isalnum() in > dlib/dlib.h: > > https://git.dillo-browser.org/dillo/tree/dlib/dlib.h?id=7c6ccebe61077902160… > > I would be inclined to add the extra wrappers there and use the > dIsspace, dIsalnum... macros instead of doing the explicit casting. > > Additionally, I think it would be safer to also switch all these ctype > macros to static inline functions so we cover accidental castings from > unexpected types with an error instead of a warning: > > static inline int dIsalnum(unsigned char c) { return isalnum(c); } > > Example: > > % cat foo.c > #include <ctype.h> > static inline int dIsalnum(unsigned char c) { return isalnum(c); } > #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) > > int main(void) > { > char *a = "a"; > dIsalnum(a); > dIsalnum_unsafe(a); > > return 0; > } > > % gcc foo.c -o foo > foo.c: In function ‘main’: > foo.c:8:18: error: passing argument 1 of ‘dIsalnum’ makes integer from pointer without a cast [-Wint-conversion] > 8 | dIsalnum(a); > | ^ > | | > | char * > foo.c:2:42: note: expected ‘unsigned char’ but argument is of type ‘char *’ > 2 | static inline int dIsalnum(unsigned char c) { return isalnum(c); } > | ~~~~~~~~~~~~~~^ > In file included from foo.c:1: > foo.c:3:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > 3 | #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) > | ^ > foo.c:9:9: note: in expansion of macro ‘dIsalnum_unsafe’ > 9 | dIsalnum_unsafe(a); > | ^~~~~~~~~~~~~~~ > [...] 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! Thank you!

Jan. 12, 2026

Re: Include missing <stdlib.h> for calloc(3) and exit(3)

by Leonardo Taccari

Hello Rodrigo, Rodrigo Arias writes: > Hi, > > On Mon, Jan 12, 2026 at 11:04:07AM +0100, Leonardo Taccari wrote: > >Hello! > > > >When trying to build current HEAD of dillo in NetBSD the build fails > >with: > > > > [...] > > g++ ... -o dialog.o dialog.cc > > [...] > > dialog.cc:38:1: note: 'calloc' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > > 37 | #include "dlib/dlib.h" > > +++ |+#include <cstdlib> > > 38 | > > dialog.cc:192:11: error: 'exit' was not declared in this scope > > 192 | exit(1); > > | ^~~~ > > dialog.cc:192:11: note: 'exit' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > > *** [dialog.o] Error code 1 > > [...] > > > >Including <stdlib.h> fixes that and the attached patch does that. > > Thanks!, merged in: > > https://git.dillo-browser.org/dillo/commit/?id=7c6ccebe61077902160798e5af46… > [...] Thank you very much for quickly applying it!

Jan. 12, 2026

Re: Avoid ctype(3) abuses

by Rodrigo Arias

Hi, On Mon, Jan 12, 2026 at 11:05:17AM +0100, Leonardo Taccari wrote: >Hello! > >Most ctype(3) functions usage abuses an undefined behavior of passing >values outside integers outside EOF or the range representable as >unsigned char. > >On NetBSD 11 and newer such incorrect behaviors crashes applications >violating that and due that Dillo easily crash by just visiting, e.g. ><https://www.NetBSD.org/>. > >For possible further information please give a look to ><https://man.NetBSD.org/ctype.3#CAVEATS>. Interesting! >I have grep-ed all such uses and added the relevant cast to uchar_t >similar to other ctype(3) calls already present and in that way I can >also confirm that Dillo no longer crashes. Thanks for the patch and tests. We have wrappers that do just that for isspace() and isalnum() in dlib/dlib.h: https://git.dillo-browser.org/dillo/tree/dlib/dlib.h?id=7c6ccebe61077902160… I would be inclined to add the extra wrappers there and use the dIsspace, dIsalnum... macros instead of doing the explicit casting. Additionally, I think it would be safer to also switch all these ctype macros to static inline functions so we cover accidental castings from unexpected types with an error instead of a warning: static inline int dIsalnum(unsigned char c) { return isalnum(c); } Example: % cat foo.c #include <ctype.h> static inline int dIsalnum(unsigned char c) { return isalnum(c); } #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) int main(void) { char *a = "a"; dIsalnum(a); dIsalnum_unsafe(a); return 0; } % gcc foo.c -o foo foo.c: In function ‘main’: foo.c:8:18: error: passing argument 1 of ‘dIsalnum’ makes integer from pointer without a cast [-Wint-conversion] 8 | dIsalnum(a); | ^ | | | char * foo.c:2:42: note: expected ‘unsigned char’ but argument is of type ‘char *’ 2 | static inline int dIsalnum(unsigned char c) { return isalnum(c); } | ~~~~~~~~~~~~~~^ In file included from foo.c:1: foo.c:3:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 3 | #define dIsalnum_unsafe(c) isalnum((unsigned char) (c)) | ^ foo.c:9:9: note: in expansion of macro ‘dIsalnum_unsafe’ 9 | dIsalnum_unsafe(a); | ^~~~~~~~~~~~~~~ Best, Rodrigo.

Jan. 12, 2026

Re: Include missing <stdlib.h> for calloc(3) and exit(3)

by Rodrigo Arias

Hi, On Mon, Jan 12, 2026 at 11:04:07AM +0100, Leonardo Taccari wrote: >Hello! > >When trying to build current HEAD of dillo in NetBSD the build fails >with: > > [...] > g++ ... -o dialog.o dialog.cc > [...] > dialog.cc:38:1: note: 'calloc' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > 37 | #include "dlib/dlib.h" > +++ |+#include <cstdlib> > 38 | > dialog.cc:192:11: error: 'exit' was not declared in this scope > 192 | exit(1); > | ^~~~ > dialog.cc:192:11: note: 'exit' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' > *** [dialog.o] Error code 1 > [...] > >Including <stdlib.h> fixes that and the attached patch does that. Thanks!, merged in: https://git.dillo-browser.org/dillo/commit/?id=7c6ccebe61077902160798e5af46… Best, Rodrigo

Jan. 12, 2026