I had a look at what's going on there. My understanding (with the caveat that the code of s_server is quite hard to follow, even within GDB) is that when the socket receives the packet, the server goes on and try to establish a connection, only to find out that it cannot because it has an inconsistent configuration (DTLS1 being disabled on seclevel 2 on Ubuntu), thus erroring out early, before it actually reads from the socket, thus triggering the loop all over again. This does not happen with TCP-based protocols, I assume because the underlying stream socket is closed (haven't checked the details though).
Fixing this cleanly would probably be a bit tricky (do we want to abort() the application? If not, what do we do with the incoming datagram?) but isn't very urgent either as it is an issue with the s_server code, which AIUI is a debugging tool. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1947588 Title: Infinite Loop in OpenSSL s_server Status in openssl package in Ubuntu: Confirmed Status in openssl source package in Focal: Confirmed Status in openssl source package in Impish: Confirmed Status in openssl source package in Jammy: Confirmed Bug description: Launching openssl s_server as follows: $ openssl s_server -nocert -psk 01020304 -dtls1 And using openssl s_client to connect to it like this: $ openssl s_client -dtls1 -psk 01020304 Results in s_server entering an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ...and so on... I have confirmed that upstream OpenSSL does not have this issue in a default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug with these commands (https://github.com/openssl/openssl/issues/16707) and it was while working on the fix for that issue (https://github.com/openssl/openssl/pull/16838) that I noticed this problem in the Ubuntu packages. $ lsb_release -rd Description: Ubuntu 21.04 Release: 21.04 $ apt-cache policy openssl openssl: Installed: 1.1.1j-1ubuntu3.5 Candidate: 1.1.1j-1ubuntu3.5 Version table: *** 1.1.1j-1ubuntu3.5 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1j-1ubuntu3 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages $ openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Mon Aug 23 17:02:39 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1947588/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
