Received: by 10.192.165.148 with SMTP id m20csp1276809imm; Wed, 2 May 2018 18:09:13 -0700 (PDT) X-Google-Smtp-Source: AB8JxZopa8C22hMjKNqWy56I0xuiEUBvGT1q9+4c2DoX5ynzlWDGB18VMtdQFj/vshaw/OToKBZ0 X-Received: by 10.98.217.217 with SMTP id b86mr21440687pfl.41.1525309753457; Wed, 02 May 2018 18:09:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525309753; cv=none; d=google.com; s=arc-20160816; b=kOl1eGabsAmZIqZq4wQat+nfAUYN9/3Hfn/Ix6dExsjI8hx/eBM32Q/qI1MoiRWa// yu7nyswcfB4SaV7oK51JFtyq6uwetM7zepyVwcBJACKZ5Q3byS+gOBy3ef9jzGR+dYXM 85u2wMwWhgJ51WAoR1coruiDYWm4Fs1PK9jyIyb+Y2dwCHcLryr42LFZsrJAyZ7jwIeN Pc6Prqo+ZiHcbEt34fMUq/A2ZsoXCjDWNeHmfWPJLzFH9wAAaL9hDMHiZVmfokHLYorw v3Cc1Cu/3AT77kxevj/B7qqqsCZUN3J2t6Lrrljf35CMavb9UyQ9+4oTXdJk+0fQlJqw 0/3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=Tfcfc5YwZKOAFJuYqhQ5UkIccMIxnLqvsm9NbYENQCc=; b=gumCmzwi9jNLlKEVL5KcqiOYsMwxogLFbY7LWxpzindDmSGEvOxThyAwPiKm+bOv62 ibTXtDg2tgGpXmXQwt3Z80EWQE82P3POwcGm+mLx2AKwQYD3MmLPvzxzHhUYESpoXvvy yeCxMEqpVhpoFXWnnUpPUCLhptZQnKOJIeVfv17mfV8/Ylho0WSqKUyB9/cOJgOu5iuI cvA0kZ9N2sg4XBM2IT98ixQPMIhU2JT2iwESbGTg8LhLLqVUgLy+6cPKdteQLHSfNy+a yqSsXtwa5qE6SS4meWOvQlmj6+8oRqNGuWDhzPlO/w4kW6DOhHD230Bb+IWR3eQcT7u3 PrnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@umn.edu header.s=20160920 header.b=mpEDbChB; 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=pass (p=NONE sp=NONE dis=NONE) header.from=umn.edu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v196-v6si10505121pgb.460.2018.05.02.18.08.47; Wed, 02 May 2018 18:09:13 -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; dkim=pass header.i=@umn.edu header.s=20160920 header.b=mpEDbChB; 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=pass (p=NONE sp=NONE dis=NONE) header.from=umn.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751989AbeECBID (ORCPT + 99 others); Wed, 2 May 2018 21:08:03 -0400 Received: from mta-p4.oit.umn.edu ([134.84.196.204]:45318 "EHLO mta-p4.oit.umn.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751745AbeECBH7 (ORCPT ); Wed, 2 May 2018 21:07:59 -0400 Received: from localhost (localhost [127.0.0.1]) by mta-p4.oit.umn.edu (Postfix) with ESMTP id 7D626565; Thu, 3 May 2018 01:07:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=umn.edu; h= content-type:content-type:subject:subject:message-id:date:date :from:from:references:in-reply-to:received:mime-version:received :received:received; s=20160920; t=1525309678; x=1527124079; bh=M V+YGdy6F7Btb3BIsEkWnybhdVeloUVagYqKCv7lDO0=; b=mpEDbChBQkT25t/Pg VrhFIQQVKstVi0hEsq76vodgoFx+FP3lAJwfHWSI1YBuTcnnGyrykE9PU3fe9FS+ RcpxXNwv8CDfdkblomkWCcfI32TiZ3rTuwRuaHpVhoHZTMlPxXaOgrEYTFBmg4Zz JD1pVNhlDSBq1W6NA3kUlGvg2ISDbSz/zakkrXUdhKRJwNBjyoiP2c9QcnHapOC7 yC5xiPkUx7aU+o4PENS6E0PWLVDr1YGPYoWOJas2Pbo3zF05ADIWbfTLyMQ7VE7w fS8a+pgvBmO7XimUtys588/0+5KlrQZy0hxYDEF8mAzGGuhxY8WRm0M+gtCuJR4/ eYS9g== X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p4.oit.umn.edu ([127.0.0.1]) by localhost (mta-p4.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKJFrEFAqwU3; Wed, 2 May 2018 20:07:58 -0500 (CDT) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: wang6495) by mta-p4.oit.umn.edu (Postfix) with ESMTPSA id 43D8A577; Wed, 2 May 2018 20:07:58 -0500 (CDT) Received: by mail-io0-f173.google.com with SMTP id e78-v6so19758939iod.0; Wed, 02 May 2018 18:07:58 -0700 (PDT) X-Gm-Message-State: ALQs6tBI6iYoE0PMU3VPG+obQxopPXLNlQNXxyPDKDkGy6vs1umJa7w8 n7euBFTMwRo889cRNOyyH2/niPh3QnHyC2782G4= X-Received: by 2002:a6b:21cb:: with SMTP id h194-v6mr21725926ioh.181.1525309677969; Wed, 02 May 2018 18:07:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:6f07:0:0:0:0:0 with HTTP; Wed, 2 May 2018 18:07:17 -0700 (PDT) In-Reply-To: <20180502232352.GJ5105@localhost.localdomain> References: <1525299165-27098-1-git-send-email-wang6495@umn.edu> <20180502232352.GJ5105@localhost.localdomain> From: Wenwen Wang Date: Wed, 2 May 2018 20:07:17 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] sctp: fix a potential missing-check bug To: Marcelo Ricardo Leitner Cc: Kangjie Lu , Vlad Yasevich , Neil Horman , "David S. Miller" , "open list:SCTP PROTOCOL" , "open list:NETWORKING [GENERAL]" , open list , Wenwen Wang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marcelo, I guess I worked on an old version of the kernel. I will re-submit the patch. Sorry :( Wenwen On Wed, May 2, 2018 at 6:23 PM, Marcelo Ricardo Leitner wrote: > Hi Wenwen, > > On Wed, May 02, 2018 at 05:12:45PM -0500, Wenwen Wang wrote: >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len >> and max_len to check whether it is in the appropriate range. If it is not, >> an error code -EINVAL will be returned. This is enforced by a security >> check. But, this check is only executed when 'val' is not 0. In fact, if > > Which makes sense, no? Especially if considering that 0 should be an > allowed value as it turns off the user limit. > >> 'val' is 0, it will be assigned with a new value (if the return value of >> the function sctp_id2assoc() is not 0) in the following execution. However, >> this new value of 'val' is not checked before it is used to assigned to > > Which 'new value'? val is not set to something new during the > function. It always contains the user supplied value. > >> asoc->user_frag. That means it is possible that the new value of 'val' >> could be out of the expected range. This can cause security issues >> such as buffer overflows, e.g., the new value of 'val' is used as an index >> to access a buffer. >> >> This patch inserts a check for the new value of 'val' to see if it is in >> the expected range. If it is not, an error code -EINVAL will be returned. >> >> Signed-off-by: Wenwen Wang >> --- >> net/sctp/socket.c | 21 ++++++++++----------- >> 1 file changed, 10 insertions(+), 11 deletions(-) >> >> diff --git a/net/sctp/socket.c b/net/sctp/socket.c >> index 80835ac..2beb601 100644 >> --- a/net/sctp/socket.c >> +++ b/net/sctp/socket.c >> @@ -3212,6 +3212,7 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned >> struct sctp_af *af = sp->pf->af; >> struct sctp_assoc_value params; >> struct sctp_association *asoc; >> + int min_len, max_len; >> int val; >> >> if (optlen == sizeof(int)) { >> @@ -3231,19 +3232,15 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned >> return -EINVAL; >> } >> >> - if (val) { >> - int min_len, max_len; >> + min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len; >> + min_len -= af->ip_options_len(sk); >> + min_len -= sizeof(struct sctphdr) + >> + sizeof(struct sctp_data_chunk); > > On which tree did you base your patch on? Your patch lacks a tag so it > defaults to net-next, and I reworked this section on current net-next > and these MTU calculcations are now handled by sctp_mtu_payload(). > > But even for net tree, I don't understand which issue you're fixing > here. Actually it seems to me that both codes seems to do the same > thing. > >> >> - min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len; >> - min_len -= af->ip_options_len(sk); >> - min_len -= sizeof(struct sctphdr) + >> - sizeof(struct sctp_data_chunk); >> + max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk); >> >> - max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk); >> - >> - if (val < min_len || val > max_len) >> - return -EINVAL; >> - } >> + if (val && (val < min_len || val > max_len)) >> + return -EINVAL; >> >> asoc = sctp_id2assoc(sk, params.assoc_id); >> if (asoc) { >> @@ -3253,6 +3250,8 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned >> val -= sizeof(struct sctphdr) + >> sctp_datachk_len(&asoc->stream); >> } >> + if (val < min_len || val > max_len) >> + return -EINVAL; >> asoc->user_frag = val; >> asoc->frag_point = sctp_frag_point(asoc, asoc->pathmtu); >> } else { >> -- >> 2.7.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >>