From ${URL} : If the TCP connections breaks without proper indication, the server side does not seem to clean some context or state. This results in the connection not being re-established after the network comes back, which breaks logging on the client because the log buffers run over and Syslog is designed to block in that case. Attacker who is able to break the TLS connection over the untrusted network, can cause DoS on the server for rsyslog service. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
RedHat who reported the problem in the past closed the issue today with the following comment: > All versions of rsyslog shipped support queuing. Therefore I am closing > this flaw NOTABUG. Some background: The bug was filed after a RedHat customer run into a problem where the remote rsyslog instance couldn't be reached and because the customer didn't set up queuing the local system couldn't be use anymore after syslog queued was filled up (normal documented behavior). It isn't clear if the remote server really recovered but the local rsyslog instance didn't catch up (i.e. did not detect that the remote server became available again to re-establish the connection to drain queue getting back to normal operation). Also nobody really verified if there's a bug within rsyslog network code or GnuTLS which maybe cause such a problem (it isn't that easy to simulate broken TCP). Again: It is well known and documented that if your rsyslog instance is configured to send its logs to a remote server that you have to configure what to do in cases like that when the remote server isn't reachable anymore. If you don't set up rsyslog properly (i.e. don't allow rsyslog to remove unsent messages when queue become full or don't configure large enough on-disk queue) it is a wanted behavior that rsyslog no longer accept messages therefor anything sending messages to that instance will fail or hang (sshd for example won't allow you to connect anymore if it can't log). @ Gentoo-Security: I am suggesting to follow RedHat and to close this bug as well.
Not a bug, see comment #1.