[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y5nkGdJOpmn1hXZo@kroah.com>
Date: Wed, 14 Dec 2022 15:56:25 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Prashanth K <quic_prashk@...cinc.com>
Cc: "Gustavo A . R . Silva" <gustavoars@...nel.org>,
Shuah Khan <skhan@...uxfoundation.org>,
John Keeping <john@...anate.com>,
Linyu Yuan <quic_linyyuan@...cinc.com>,
Pratham Pratap <quic_ppratap@...cinc.com>,
Vincent Pelletier <plr.vincent@...il.com>,
Dan Carpenter <error27@...il.com>,
Udipto Goswami <quic_ugoswami@...cinc.com>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
"# 5 . 15" <stable@...r.kernel.org>
Subject: Re: usb: f_fs: Fix CFI failure in ki_complete
On Wed, Dec 14, 2022 at 06:38:17PM +0530, Prashanth K wrote:
>
>
> On 12-12-22 07:05 pm, Greg Kroah-Hartman wrote:
> > On Mon, Dec 12, 2022 at 06:54:24PM +0530, Prashanth K wrote:
> > > Function pointer ki_complete() expects 'long' as its second
> > > argument, but we pass integer from ffs_user_copy_worker. This
> > > might cause a CFI failure, as ki_complete is an indirect call
> > > with mismatched prototype. Fix this by typecasting the second
> > > argument to long.
> >
> > "might"? Does it or not? If it does, why hasn't this been reported
> > before?
> Sorry for the confusion in commit text, We caught a CFI (Control Flow
> Integrity) failure internally on 5.15, hence pushed this patch. But later I
> came to know that CFI was implemented on 5.4 kernel for Android. Will push
> the same on ACK and share the related details there.
I will have the same questions there, namely, "why just this one
instance and why is it trigging anything"?
So please, work this out here, in public, don't bury stuff in random
vendor kernel trees. That's not the way to solve anything properly, you
know this :)
thanks,
greg k-h
Powered by blists - more mailing lists