Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp98698pxa; Fri, 31 Jul 2020 07:22:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpRCBG0pT/240ahBMS3BKOp9+jfZ+PzNzBVxHjuzOmMvIvBNcSF9+orEwWWhoZmgm7huC7 X-Received: by 2002:a05:6402:1358:: with SMTP id y24mr4258784edw.318.1596205360292; Fri, 31 Jul 2020 07:22:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596205360; cv=none; d=google.com; s=arc-20160816; b=apaK1vq+je9UwDMgdYqqRnzCaUmCk5aWuQ9EoeV8KoAKfA6eA38s27e0ja9ei/jks2 fTg8JT1aIQfK8om4zgJ1svNpS/gnpFzLeTZRHG8BN+QKgrywr5zxQNaTwKTR0us08X/s GA56fWE13hq7Zz905CBEz96FuMpS5L2R8fIlHbOxOzQdv1g4FiofvW/nqqhqao1/M/87 +986Wa+7v2AaXCP61JEemSansrhmNJaen9wN9S4VUKLhXo0b0zNIg6yXKw8OjaxJo+41 y/drT/wWGFdQUuC0z6+VkHwC8EghkiBvHpnL+wsSVGYmo6zaYY/4RLJ4lLN6Mhub21HA PZ3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=lQJK0/ve1E0e6hWzW2pqYd2rBdRRYuaaUSqi+pQDAhM=; b=atqlidDxYyGqpl8cDgPbTjbE+zL904bNnqZqBBgykTA6R0EGUuHSNX1sNuGIcZnim5 s15KZ6JaXOYf4aKYFc5aVSbdCpUqd3Pp5pN7GLt7uvsbVpEquN9gaeUpcgztClr5PnEy mP1gdAj1joZPr3dR+0X/iR0SoOTUB4EVxK0i2jovSGj2yF1QmBtQDyM+AZYpnvAu3W1z Tgycryh4HIu8Cimc9Ftrr681ORF+I1mHnPwHqu+05BL8p8zoXPDt3pzVsvwCoFRmZsTA B0SKqJbgpzc75tJNsdzrke188B3G23+Hpa6uYEydgmw6EgtN+EmuGsZVxVMv1ohNTliA HvBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=A4AXijss; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f8si5089759eji.335.2020.07.31.07.22.18; Fri, 31 Jul 2020 07:22:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=A4AXijss; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729088AbgGaOWD (ORCPT + 99 others); Fri, 31 Jul 2020 10:22:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:33314 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728697AbgGaOWD (ORCPT ); Fri, 31 Jul 2020 10:22:03 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DF1D2208E4; Fri, 31 Jul 2020 14:22:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596205322; bh=xOTUdTDtgFUE4tg3a96EHIpYVqLyrjXL2vfmrZmnmXk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A4AXijssIn9cJbmiigc2HnNHygj6LDX7SwRcO35y32gJ28dLyviyTLEowdbRQMFJH BICWi9NGqq7lv+plJy4BfbNlrvKnXbC3cv6D8jG5Iz7ArVn3YkA56UJKbZaespigHT izydEL7WKrOkda8awf2v5WwNko1uMTUmGdcPFhDk= Date: Fri, 31 Jul 2020 16:21:48 +0200 From: Greg Kroah-Hartman To: Jason Gunthorpe Cc: Leon Romanovsky , Peilin Ye , Santosh Shilimkar , "David S. Miller" , Jakub Kicinski , Dan Carpenter , Arnd Bergmann , linux-kernel-mentees@lists.linuxfoundation.org, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com, linux-kernel@vger.kernel.org Subject: Re: [Linux-kernel-mentees] [PATCH net] rds: Prevent kernel-infoleak in rds_notify_queue_get() Message-ID: <20200731142148.GA1718799@kroah.com> References: <20200730192026.110246-1-yepeilin.cs@gmail.com> <20200731045301.GI75549@unreal> <20200731053306.GA466103@kroah.com> <20200731053333.GB466103@kroah.com> <20200731140452.GE24045@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200731140452.GE24045@ziepe.ca> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 31, 2020 at 11:04:52AM -0300, Jason Gunthorpe wrote: > On Fri, Jul 31, 2020 at 07:33:33AM +0200, Greg Kroah-Hartman wrote: > > On Fri, Jul 31, 2020 at 07:33:06AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Jul 31, 2020 at 07:53:01AM +0300, Leon Romanovsky wrote: > > > > On Thu, Jul 30, 2020 at 03:20:26PM -0400, Peilin Ye wrote: > > > > > rds_notify_queue_get() is potentially copying uninitialized kernel stack > > > > > memory to userspace since the compiler may leave a 4-byte hole at the end > > > > > of `cmsg`. > > > > > > > > > > In 2016 we tried to fix this issue by doing `= { 0 };` on `cmsg`, which > > > > > unfortunately does not always initialize that 4-byte hole. Fix it by using > > > > > memset() instead. > > > > > > > > Of course, this is the difference between "{ 0 }" and "{}" initializations. > > > > > > Really? Neither will handle structures with holes in it, try it and > > > see. > > > > And if true, where in the C spec does it say that? > > The spec was updated in C11 to require zero'ing padding when doing > partial initialization of aggregates (eg = {}) > > """if it is an aggregate, every member is initialized (recursively) > according to these rules, and any padding is initialized to zero > bits;""" But then why does the compilers not do this? > The difference between {0} and the {} extension is only that {} > reliably triggers partial initialization for all kinds of aggregates, > while {0} has a number of edge cases where it can fail to compile. > > IIRC gcc has cleared the padding during aggregate initialization for a > long time. Huh? Last we checked a few months ago, no, it did not do that. > Considering we have thousands of aggregate initializers it > seems likely to me Linux also requires a compiler with this C11 > behavior to operate correctly. Note that this is not an "operate correctly" thing, it is a "zero out stale data in structure paddings so that data will not leak to userspace" thing. > Does this patch actually fix anything? My compiler generates identical > assembly code in either case. What compiler version? thanks, greg k-h