Bug 261244

Summary: security/stunnel 5.61 transfer() loop executes not transferring any data
Product: Ports & Packages Reporter: Dirk Meyer <dinoex>
Component: Individual Port(s)Assignee: Ryan Steinmetz <zi>
Status: Closed Overcome By Events    
Severity: Affects Many People CC: diizzy, dinoex
Priority: --- Keywords: needs-qa, regression
Version: LatestFlags: bugzilla: maintainer-feedback? (zi)
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Suggested patch none

Description Dirk Meyer freebsd_committer freebsd_triage 2022-01-16 12:15:53 UTC 

    


    


      



        
          Comment 1
        

        
          Dirk Meyer

        

        
            freebsd_committer
            freebsd_triage
        

        
          2022-01-16 12:18:32 UTC
        

      






I run stunnel from inetd.
after upgrade from stunnel 5.60 to stunnel 5.61
I get this fatal error an every connection:
        transfer() loop executes not transferring any data

reverting to stunnel 5.60 fixes the problem.

Jan 15 00:00:05 smtp stunnel[39828]: LOG5[ui]: stunnel 5.61 on amd64-portbld-freebsd12.2 platform
Jan 15 00:00:05 smtp stunnel[39828]: LOG5[ui]: Compiled/running with OpenSSL 1.1.1m  14 Dec 2021
Jan 15 00:00:05 smtp stunnel[39828]: LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI
Jan 15 00:00:05 smtp stunnel[39828]: LOG5[ui]: Reading configuration from file /usr/local/etc/stunnel/stunnel.conf
Jan 15 00:00:05 smtp stunnel[39828]: LOG5[ui]: UTF-8 byte order mark not detected
Jan 15 00:00:05 smtp stunnel[39828]: LOG5[ui]: Configuration successful
Jan 15 00:00:05 smtp stunnel[39828]: LOG5[ui]: Switched to chroot directory: /
Jan 15 00:00:05 smtp stunnel[39828]: LOG5[0]: Service [stunnel] accepted connection from 2a0b:f840::12:52338
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: transfer() loop executes not transferring any data
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: please report the problem to Michal.Trojnara@stunnel.org
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: stunnel 5.61 on amd64-portbld-freebsd12.2 platform
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: Compiled/running with OpenSSL 1.1.1m  14 Dec 2021
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: protocol=TLSv1.3, SSL_pending=0, SSL_has_pending=0
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: sock_open_rd=Y, sock_open_wr=Y
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: SSL_RECEIVED_SHUTDOWN=n, SSL_SENT_SHUTDOWN=n
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: sock_can_rd=n, sock_can_wr=n
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: ssl_can_rd=n, ssl_can_wr=n
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: read_wants_read=Y, read_wants_write=n
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: write_wants_read=n, write_wants_write=Y
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: shutdown_wants_read=n, shutdown_wants_write=n
Jan 15 00:00:06 smtp stunnel[39828]: LOG3[0]: socket input buffer: 7 byte(s), TLS input buffer: 0 byte(s)
Jan 15 00:00:06 smtp stunnel[39828]: LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 1 byte(s) sent to socket

Mail to Upstream was sent.

    


    


      



        
          Comment 2
        

        
          Dirk Meyer

        

        
            freebsd_committer
            freebsd_triage
        

        
          2022-01-17 23:45:21 UTC
        

      






Upstream has fixed the problem in "stunnel-5.62b1.tar.gz"

Upstream will issue a bugfix release today or tomorrow.

    


    


      



        
          Comment 3
        

        
          Dirk Meyer

        

        
            freebsd_committer
            freebsd_triage
        

        
          2022-01-17 23:47:56 UTC
        

      






Created attachment 231097 [details]
Suggested patch

    


    


      



        
          Comment 4
        

        
          Daniel Engberg

        

        
            freebsd_committer
            freebsd_triage
        

        
          2022-08-09 19:56:33 UTC
        

      






We're at 5.65 and submitter confirmed this issue being resolved