Branch: refs/heads/master Home: https://github.com/ngircd/ngircd Commit: 5b23b6ef39fac48e2a0327d9cdc1bea015e65e94 https://github.com/ngircd/ngircd/commit/5b23b6ef39fac48e2a0327d9cdc1bea015e6... Author: James <admin@floretos.com> Date: 2026-07-12 (Sun, 12 Jul 2026) Changed paths: M src/ngircd/conn.c Log Message: ----------- Disconnect clients that send data without a command terminator Handle_Buffer() scans the read buffer for a CR/LF command terminator and, when none is found, simply breaks out of the parsing loop without draining the buffer or closing the connection. The existing "Request too long" safeguard that disconnects over-long commands is only reached *after* a terminator has been located. As a result, a connection that sends COMMAND_LEN (513) or more bytes containing no CR or LF at all -- for example binary garbage, or a TLS ClientHello accidentally (or deliberately) sent to a plain-text listening port -- is never drained and never closed. Conn_Handler() then sets the io_dispatch() timeout to zero whenever a read buffer holds COMMAND_LEN or more bytes (command_available == true), so the main loop busy-spins, calling Handle_Buffer() on the same unparseable buffer over and over, pinning one CPU core at 100%. This is triggerable by any unauthenticated client and is an easy remote denial of service: a single stray TLS-to-plain-text connection is enough to peg a core indefinitely. Fix it by applying the same "Request too long" handling to the no-terminator case: if the read buffer already holds a whole command's worth of data without any terminator, it can never become a valid IRC message, so disconnect the client instead of spinning on it. Reproduce (pins a core at 100% CPU without this patch): perl -e 'print "A" x 600' | nc <host> <plain-text-port> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Closes #343 To unsubscribe from these emails, change your notification settings at https://github.com/ngircd/ngircd/settings/notifications