From owner-freebsd-ipfw@freebsd.org Fri Dec 11 17:05:54 2020 Return-Path: Delivered-To: freebsd-ipfw@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 7C4AA4B556B for ; Fri, 11 Dec 2020 17:05:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Csxxt2mJXz4d3R for ; Fri, 11 Dec 2020 17:05:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 5CEF94B55DE; Fri, 11 Dec 2020 17:05:54 +0000 (UTC) Delivered-To: ipfw@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 5CB954B55DD for ; Fri, 11 Dec 2020 17:05:54 +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 4Csxxt0zVqz4cmv for ; Fri, 11 Dec 2020 17:05:54 +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 0FC7D65B5 for ; Fri, 11 Dec 2020 17:05:54 +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 0BBH5rwL035237 for ; Fri, 11 Dec 2020 17:05:53 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0BBH5rxM035236 for ipfw@FreeBSD.org; Fri, 11 Dec 2020 17:05:53 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: ipfw@FreeBSD.org Subject: [Bug 230755] natd sends wrong sequence number when a retransmitted PASV packet comes in Date: Fri, 11 Dec 2020 17:05:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.4-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: longwitz@incore.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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-ipfw@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 17:05:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230755 longwitz@incore.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |longwitz@incore.de --- Comment #1 from longwitz@incore.de --- The patch given in this bug report waits for commit. I like to describe some technical background for the problem. Relevant are the functions AddSeq() and GetDeltaSeqOut() in the source alias_db.c. AddSeq() start with the following comment: When a TCP packet has been altered in length, save this information in a circular list. If enough packets have been altered, then this list will begin to overwrite itself. The important word here is "circular". The used list has N_LINK_TCP_DATA (=3D3) entries and AddSeq() writes to the list circual from top to bottom and holds the actual index of the list in the variable lnk->data.tcp->state.index. The function GetDeltaSeqOut() starts with the following comment: Find out how much the sequence number has been altered for an outgoing TCP packet. To do this, a circular list of ACK numbers where the TCP packet size was altered is searched. The circular list read by GetDeltaSeqOut() is the same list filled by AddSeq() in a circular manner before. But the function GetDeltaSeqOut() does not read the list in a circular way but sequential from top to bottom. Especially GetDeltaSeqOut() does not use the variable lnk->data.tcp->state.index in any way. That is the leak ! Example: If a "227 Entering Passive Mode" packet must be retransmittet and the length changes from 51 to 50, then we have three cases for the list: case 1: index 0: original packet 51 index 1: retransmitted packet 50 index 2: not relevant case 2: index 0: not relevant index 1: original packet 51 index 2: retransmitted packet 50 case 3: index 0: retransmitted packet 50 index 1: not relevant index 2: original packet 51 Only in case 3 the function GetDeltaSeqOut() finds the correct length 50, in case 1 and 2 GetDeltaSeqOut() finds length 51 and TCP fails. Exactly this problem is solved by the patch given in this bug report for GetDeltaSeqOut() and (identical constellation) GetDeltaAckIn(). The function GetDeltaSeqOut() with the patch included searches the list from bottom to top and starts with the correct index lnk->data.tcp->state.index. --=20 You are receiving this mail because: You are the assignee for the bug.=