Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3728578imm; Thu, 17 May 2018 13:43:24 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoWaKBbSndToLqTMVE8nL4gioogNr49L03zGrJuddiD3yLP0IordWJUY1UsMOzkkesjxZT0 X-Received: by 2002:a17:902:848e:: with SMTP id c14-v6mr6583548plo.129.1526589804437; Thu, 17 May 2018 13:43:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526589804; cv=none; d=google.com; s=arc-20160816; b=MQz5Hp1DOq6HNpmGLSGEHqG5OHD1hLcKtuuRlxy0qR7kosPEtA7VoKB/cW8ve7SDFs gR1NMypK0s+J4S5A3uJwxmfMqhXhhQL8TEaIgDhAYWdKvEZjKQcMBt189IRT+nXZW/u2 kgdEVxPc66i4auQOwjK0IxRQgSwINzvhpLZwtgAOe6lp+/3OE1Q2QHp9YSozADr7Bx2b oS7krfWOitEvUXfHRKVQxNNfsjzZ7K42/NeI88R8M3ZD9o1z4Avu1Kip4LUJvIxgSD0g sfqTh5JQxikP5T7JBZo1xzhopnMw+OO1joged1+kWu1nh/rKhxxTfQocUUnjNZQk/68K V1Lg== 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 :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=zH7qFt9Npa9Ep6cxmwFGzo68bojNKLFP2yEdVOLnWZs=; b=UlCPVeN3cP6aw6n/mCRwKFjoOl2VH9nqTuw92y3ZZlRPBkrOrdOT8eljwoD0D3662S TLMhYgrXZwBYSM8fwYJ6AEv9SySBAW0iC2LgvdEQu+pzmEN0Kj1pfzKxOF9CG+m5MJsH k5j671cS8I3HUogm6Bivp6d+oxAH4EBlwD/wxktbGlWmntCfY7BrQq6EwVtMgsAFRBQV VL49ZXvmH/eN8KRDW4H3Qgyx/etTUve09h4wxykqn2Jarf3AYRqAb97xZFrTN/6zIYN1 GUjvPWMOEtbkp9ckf/P96gkarTTVO8c5SQ5fAi2W61zWykzJVvdCHQQcpnJ4WmCCROPd TGrA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b18-v6si5993270pfi.254.2018.05.17.13.43.09; Thu, 17 May 2018 13:43:24 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752121AbeEQUmz (ORCPT + 99 others); Thu, 17 May 2018 16:42:55 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:34966 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788AbeEQUmx (ORCPT ); Thu, 17 May 2018 16:42:53 -0400 Received: from localhost (67.110.78.66.ptr.us.xo.net [67.110.78.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 01BA714173939; Thu, 17 May 2018 13:42:52 -0700 (PDT) Date: Thu, 17 May 2018 16:42:52 -0400 (EDT) Message-Id: <20180517.164252.466789510812778167.davem@davemloft.net> To: mmullins@fb.com Cc: netdev@vger.kernel.org, davejwatson@fb.com, linux-kernel@vger.kernel.org, aviadye@mellanox.com, doronrk@fb.com Subject: Re: [PATCH net] tls: don't use stack memory in a scatterlist From: David Miller In-Reply-To: <1526588924.24138.2.camel@fb.com> References: <20180516174841.2119-1-mmullins@fb.com> <20180517.145056.1635507477734784563.davem@davemloft.net> <1526588924.24138.2.camel@fb.com> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 17 May 2018 13:42:53 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Matt Mullins Date: Thu, 17 May 2018 20:28:46 +0000 > On Thu, 2018-05-17 at 14:50 -0400, David Miller wrote: >> I'm surprised this problem wasn't discovered sooner. How exactly did you >> discover it? Did you actually see it trigger or is this purely from code >> inspection? > > Honestly, I'm not sure how it got uncovered, but it was observed at > runtime. Doron Roberts-Kedes hit a null pointer dereference so we > turned on CONFIG_DEBUG_SG -- then it became a proper > BUG_ON(!virt_addr_valid(buf)); in sg_set_buf. Fair enough, thanks for the info.