[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200728084137.GC2571@kadam>
Date: Tue, 28 Jul 2020 11:41:37 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Peilin Ye <yepeilin.cs@...il.com>
Cc: Kashyap Desai <kashyap.desai@...adcom.com>,
Sumit Saxena <sumit.saxena@...adcom.com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Shivasharan S <shivasharan.srikanteshwara@...adcom.com>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
linux-kernel-mentees@...ts.linuxfoundation.org,
megaraidlinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [Linux-kernel-mentees] [PATCH] scsi/megaraid: Prevent
kernel-infoleak in kioc_to_mimd()
On Mon, Jul 27, 2020 at 05:02:35PM -0400, Peilin Ye wrote:
> hinfo_to_cinfo() does no operation on `cinfo` when `hinfo` is NULL,
> causing kioc_to_mimd() to copy uninitialized stack memory to userspace.
> Fix it by initializing `cinfo` with memset().
But "hinfo" can't be NULL so this patch isn't required. It's a bit
hard for Smatch to follow the code.
We know that "opcode" is 82 so the buffer is allocated by mimd_to_kioc()
-> mraid_mm_attach_buf().
Generally, don't silence static checker warnings unless it makes the
code more readable. It's the checker writer's job to fix their own code.
In this case, that's me, but parsing the code is quite complicated and I
don't have a plan for how to fix it.
regards,
dan carpenter
Powered by blists - more mailing lists