linux-kernel - Re: usb: f_fs: Fix CFI failure in ki

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]

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