[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <36aecc9a-ac30-436f-b42b-39f63513d743@moroto.mountain>
Date: Tue, 9 Jan 2024 16:22:07 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: "Gustavo A. R. Silva" <gustavo@...eddedor.com>
Cc: Kees Cook <keescook@...omium.org>,
Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
linux-hardening@...r.kernel.org, error27@...il.com,
gustavoars@...nel.org, Bryan Tan <bryantan@...are.com>,
Vishnu Dasa <vdasa@...are.com>,
VMware PV-Drivers Reviewers <pv-drivers@...are.com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, vegard.nossum@...cle.com,
darren.kenny@...cle.com, syzkaller <syzkaller@...glegroups.com>
Subject: Re: [PATCH v2 2/2] VMCI: Fix memcpy() run-time warning in
dg_dispatch_as_host()
On Tue, Jan 09, 2024 at 06:31:41AM -0600, Gustavo A. R. Silva wrote:
>
> You're arguing that fortify caused a problem.
Yes.
Before: Code working correctly
After: Kernel Panic
At first, I started to question if I was going mad, but then I looked
through the email thread and Harshit tested it and proved that the
kernel does actually panic depending on the .config.
I mean realistically we should backport this patch to old kernels,
right? And if we had to assign a Fixes tag to this it would need to be
the commit which adds Fortify to the kernel. Prior to that commit the
code was fine.
Again, I'm not saying that Fortify is bad overall. Probably in DnD it
would be Chaotic Good where it's overall good but sometimes a pain.
regards,
dan carpenter
Powered by blists - more mailing lists