lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ