Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Sasha Levin <Alexander.Levin@microsoft.com>
To:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
CC:     Xin Long <lucien.xin@gmail.com>,
        "David S . Miller" <davem@davemloft.net>,
        Sasha Levin <Alexander.Levin@microsoft.com>
Subject: [PATCH AUTOSEL for 4.14 045/100] sctp: set sender next_tsn for the
 old result with ctsn_ack_point plus 1
Thread-Topic: [PATCH AUTOSEL for 4.14 045/100] sctp: set sender next_tsn for
 the old result with ctsn_ack_point plus 1
Thread-Index: AQHTlMne8tJJySJruEeJfT1I5urOjA==
Date:   Wed, 24 Jan 2018 04:14:46 +0000
Message-ID: <20180124041414.32065-45-alexander.levin@microsoft.com>
References: <20180124041414.32065-1-alexander.levin@microsoft.com>
In-Reply-To: <20180124041414.32065-1-alexander.levin@microsoft.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1185987d-6af3-4430-338d-08d562e11226
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 04:14:46.6826
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1080
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Xin Long <lucien.xin@gmail.com>

[ Upstream commit 52a395896a051a3d5c34fba67c324f69ec5e67c6 ]

When doing asoc reset, if the sender of the response has already sent some
chunk and increased asoc->next_tsn before the duplicate request comes, the
response will use the old result with an incorrect sender next_tsn.

Better than asoc->next_tsn, asoc->ctsn_ack_point can't be changed after
the sender of the response has performed the asoc reset and before the
peer has confirmed it, and it's value is still asoc->next_tsn original
value minus 1.

This patch sets sender next_tsn for the old result with ctsn_ack_point
plus 1 when processing the duplicate request, to make sure the sender
next_tsn value peer gets will be always right.

Fixes: 692787cef651 ("sctp: implement receiver-side procedures for the SSN/=
TSN Reset Request Parameter")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
 net/sctp/stream.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sctp/stream.c b/net/sctp/stream.c
index aa629654d27e..9ea6057ed28b 100644
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -541,7 +541,7 @@ struct sctp_chunk *sctp_process_strreset_tsnreq(
 		i =3D asoc->strreset_inseq - request_seq - 1;
 		result =3D asoc->strreset_result[i];
 		if (result =3D=3D SCTP_STRRESET_PERFORMED) {
-			next_tsn =3D asoc->next_tsn;
+			next_tsn =3D asoc->ctsn_ack_point + 1;
 			init_tsn =3D
 				sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map) + 1;
 		}
--=20
2.11.0