Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756027AbcKVRmx (ORCPT ); Tue, 22 Nov 2016 12:42:53 -0500 Received: from mga14.intel.com ([192.55.52.115]:55593 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754009AbcKVRmq (ORCPT ); Tue, 22 Nov 2016 12:42:46 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,533,1473145200"; d="scan'208";a="34490807" From: "Duyck, Alexander H" To: "gregkh@linuxfoundation.org" , "edumazet@google.com" CC: "maan@tuebingen.mpg.de" , "linux-kernel@vger.kernel.org" , "ast@kernel.org" , "stable@vger.kernel.org" , "willemb@google.com" , "jslaby@suse.cz" , "davem@davemloft.net" , "yibyang@cisco.com" Subject: Re: Linux 4.4.34 Thread-Topic: Linux 4.4.34 Thread-Index: AQHSROHLnoffZaunj0OqG3byajfXn6Dlwf4AgAACAwCAAAfBgA== Date: Tue, 22 Nov 2016 17:41:53 +0000 Message-ID: <1479836511.681.165.camel@intel.com> References: <20161121092855.GA20976@kroah.com> <20161122165912.GA19939@tuebingen.mpg.de> <20161122170654.GA20022@kroah.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.134.2.24] Content-Type: text/plain; charset="utf-8" Content-ID: <1775503B48F489429679CC420927A18C@intel.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id uAMHh30o019232 Content-Length: 2047 Lines: 53 On Tue, 2016-11-22 at 09:14 -0800, Eric Dumazet wrote: > On Tue, Nov 22, 2016 at 9:06 AM, Greg KH wrote: > > > > On Tue, Nov 22, 2016 at 05:59:12PM +0100, Andre Noll wrote: > > > > > > On Mon, Nov 21, 10:28, Greg KH wrote > > > > > > > > I'm announcing the release of the 4.4.34 kernel. > > > > > > > > All users of the 4.4 kernel series must upgrade. > > > > > > This update broke PXE boot on our 4-way AMD boxes. The kernel panics in > > > eth_type_trans(), presumably during kernel-level IP autoconfiguration, > > > see [1]. Bisection points me at 5c67f947 (net: __skb_flow_dissect() > > > must cap its return value). And indeed, reverting this commit fixes > > > the problem for me. > > > > > > Investigation showed that the real problem is not the change in the > > > above commit per se (i.e., capping ->thoff) but the fact that in the > > > success case, where we jump to the "out_good" label, ->thoff is now > > > set *after* ->n_proto and ->ip_proto. I fail to see how order matters > > > here, but it clearly does, since the crash is 100% reproducible, > > > and is fixed by the commit below (on top of v4.4.34). > > > > > > Please consider applying something like the patch below for mainline > > > and -stable. > > > > If this issue is also the same for Linus's tree, we should cc: netdev so > > that the patch can get into there, right? > > > > thanks, > > > > greg k-h > > We definitely want to fix the real bug, not working around it. > > Seems an aliasing problem, key_control and key_basic might point to > adjacent memory > and a barrier() would solve the issue as well. > > Adding a test in fast path looks overkill to me. > > Thanks. I was wondering if we shouldn't just cap all cases? It seems like this could potentially return a value greater than skb- >len in the "good" case since things like IP header length isn't validated other then making sure it meets the minimum value, and if there isn't a recognized L4 header after that we could return that as a final value. - Alex