Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1409734imm; Wed, 6 Jun 2018 15:50:15 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLRX7cXESmOVOLe+oIoya2zcXaWB33UUsBUlvJzmiZROkyGhB1umOZWVP+bcOUfrMn2ktia X-Received: by 2002:a65:5807:: with SMTP id g7-v6mr4002041pgr.409.1528325415164; Wed, 06 Jun 2018 15:50:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528325415; cv=none; d=google.com; s=arc-20160816; b=lIjT+Px4hHx6dQuvJSdCkFx6FDWGwtAFnZZIJGF/c0dn0OsKE5X1YgKw+Ed5PBzW0O EGE0YpUDnj2urQinpn7FTcHWKLI6LshGjNDk33yNDxBAgSBLTC5DWZ9EXDFFd3q4GMGt GVxnxRxASuzLI2QLLfIoHz847sdQbifOKFOJ/Ce88aMgfdUA/0HEKUm7e+3+RM/73uTn 0OISA2qTRxhoCpn33+SwXIqY0cm3rBPH2F9RYvMLhElSAegEWeTfwN/XQaFAJGkGO2zG RGcDAe+dnkasxaql1YRL2BuqvvA97p/5WgSJHcKhq3xt9fquzQZktWXc4w4TLjd3eOjZ tRSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=webRfRAJ06KRQTh9AZcXH+DTxFULYiSViDV+3mBWjzc=; b=wV2gHda7iFUF9nx9sxogfIfdmrAL9DowTvjoMjO6WC7cvA+ZifIzR+yCgTgalFAgZZ xv5+3yRZ5Pl78lShJqMRv1CtmGkNJ2AjVHZmarEUWZqTTuLvs8hRQInkO9GG3nKHtik1 J3HlcbkqKtWEPUD3YT+B46atehXFekEs15N5Hmj8WwJ1GX+G98hRT22+izBA4GvkKw+R XMu0c2pQmnTTeY0N9nFwRMupQIRL5y1weJwnqxrrK17e1nBBfeH+3nHUe13VHXzJQMQj WLfPc61en3Xg+Ity1JBi2y17bqCDHRIyrjCc1fVHDmi6RFDrXTEB9urP/v7ylkAvaSSL De9w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r8-v6si37930692plj.40.2018.06.06.15.50.00; Wed, 06 Jun 2018 15:50:15 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932138AbeFFWbz (ORCPT + 99 others); Wed, 6 Jun 2018 18:31:55 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:48112 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932068AbeFFWby (ORCPT ); Wed, 6 Jun 2018 18:31:54 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126] helo=xylophone) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1fQgy3-00019a-Oe; Wed, 06 Jun 2018 23:31:47 +0100 Message-ID: <1528324307.2289.61.camel@codethink.co.uk> Subject: Re: [PATCH 4.4 19/92] sctp: delay the authentication for the duplicated cookie-echo chunk From: Ben Hutchings To: Xin Long , Marcelo Ricardo Leitner , Neil Horman Cc: stable@vger.kernel.org, "David S. Miller" , Greg Kroah-Hartman , LKML Date: Wed, 06 Jun 2018 23:31:47 +0100 In-Reply-To: <20180524093200.931521036@linuxfoundation.org> References: <20180524093159.286472249@linuxfoundation.org> <20180524093200.931521036@linuxfoundation.org> Organization: Codethink Ltd. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-05-24 at 11:37 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > ------------------ > > From: Xin Long > > [ Upstream commit 59d8d4434f429b4fa8a346fd889058bda427a837 ] > > Now sctp only delays the authentication for the normal cookie-echo > chunk by setting chunk->auth_chunk in sctp_endpoint_bh_rcv(). But > for the duplicated one with auth, in sctp_assoc_bh_rcv(), it does > authentication first based on the old asoc, which will definitely > fail due to the different auth info in the old asoc. [...] > --- a/net/sctp/associola.c > +++ b/net/sctp/associola.c > @@ -1000,9 +1000,10 @@ static void sctp_assoc_bh_rcv(struct wor >   struct sctp_endpoint *ep; >   struct sctp_chunk *chunk; >   struct sctp_inq *inqueue; > - int state; >   sctp_subtype_t subtype; > + int first_time = 1; /* is this the first time through the loop */ >   int error = 0; > + int state; >   >   /* The association should be held so we should be safe. */ >   ep = asoc->ep; > @@ -1013,6 +1014,30 @@ static void sctp_assoc_bh_rcv(struct wor >   state = asoc->state; >   subtype = SCTP_ST_CHUNK(chunk->chunk_hdr->type); >   > + /* If the first chunk in the packet is AUTH, do special > +  * processing specified in Section 6.3 of SCTP-AUTH spec > +  */ > + if (first_time && subtype.chunk == SCTP_CID_AUTH) { > + struct sctp_chunkhdr *next_hdr; > + > + next_hdr = sctp_inq_peek(inqueue); > + if (!next_hdr) > + goto normal; > + > + /* If the next chunk is COOKIE-ECHO, skip the AUTH > +  * chunk while saving a pointer to it so we can do > +  * Authentication later (during cookie-echo > +  * processing). > +  */ > + if (next_hdr->type == SCTP_CID_COOKIE_ECHO) { > + chunk->auth_chunk = skb_clone(chunk->skb, > +       GFP_ATOMIC); > + chunk->auth = 1; Doesn't the first_time flag need to be cleared here (and before the other continue statement in this loop)? Ben. > + continue; > + } > + } > + > +normal: [...] -- Ben Hutchings, Software Developer   Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom