From owner-freebsd-bugs@freebsd.org Tue Jan 12 23:30:30 2021 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A7ADD4E9A8F for ; Tue, 12 Jan 2021 23:30:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4DFmyt4BTTz4qNh for ; Tue, 12 Jan 2021 23:30:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8DEDE4E9A15; Tue, 12 Jan 2021 23:30:30 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8DB214E99C5 for ; Tue, 12 Jan 2021 23:30:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFmyt3V6qz4qHy for ; Tue, 12 Jan 2021 23:30:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 66C7C5886 for ; Tue, 12 Jan 2021 23:30:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 10CNUUPr064184 for ; Tue, 12 Jan 2021 23:30:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 10CNUUdN064183 for bugs@FreeBSD.org; Tue, 12 Jan 2021 23:30:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 252624] Sockets stay in CLOSING, FIN_WAIT_X and LAST_ACK indefinitely Date: Tue, 12 Jan 2021 23:30:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: johalun@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 23:30:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252624 Bug ID: 252624 Summary: Sockets stay in CLOSING, FIN_WAIT_X and LAST_ACK indefinitely Product: Base System Version: Unspecified Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: johalun@FreeBSD.org We're running head as of March 2017 on a large number of servers. Through recent expansions we have noticed a new problem where a large amount of connections are stuck in CLOSING, FIN_WAIT_1, FIN_WAIT_2 and LAST_ACK indefinitely, until the servers runs out of memory. We don't know what is causing this but it appears that clients are not terminating the TCP connections properly. In any case, these connections should have a timeout = and be cleaned up by the kernel within reasonable time. #25986 also mentions this issue and have a suggested patch that deals with = all states but CLOSING. https://www.freebsd.org/security/advisories/FreeBSD-SA-15:13.tcp.asc claims= to have solved it but it has not. In our case we don't believe it is deliberate but if someone wanted, they c= ould easily take down servers with simple attacks like this so it is a security concern. --=20 You are receiving this mail because: You are the assignee for the bug.=