[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200731095943.GI5493@kadam>
Date: Fri, 31 Jul 2020 12:59:43 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Peilin Ye <yepeilin.cs@...il.com>,
Santosh Shilimkar <santosh.shilimkar@...cle.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel-mentees@...ts.linuxfoundation.org,
netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
rds-devel@....oracle.com, linux-kernel@...r.kernel.org
Subject: Re: [Linux-kernel-mentees] [PATCH net] rds: Prevent kernel-infoleak
in rds_notify_queue_get()
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.
>
No, there is no difference. Even struct assignments like:
foo = *bar;
can leave struct holes uninitialized. Depending on the compiler the
assignment can be implemented as a memset() or as a series of struct
member assignments.
regards,
dan carpenter
Powered by blists - more mailing lists