[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACCg+XO+D+2SWJq0C=_sWXj53L1fh-wra8dmCb3VQ4bYCZQryA@mail.gmail.com>
Date: Fri, 2 Jul 2021 23:01:57 +0800
From: Macpaul Lin <macpaul@...il.com>
To: Eugeniu Rosca <erosca@...adit-jv.com>, stable@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Felipe Balbi <balbi@...nel.org>,
Andrew Gabbasov <andrew_gabbasov@...tor.com>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
Eugeniu Rosca <roscaeugeniu@...il.com>,
Macpaul Lin <macpaul.lin@...iatek.com>,
Eddie Hung <eddie.hung@...iatek.com>
Subject: Re: [PATCH] usb: gadget: f_fs: Fix setting of device and driver data cross-references
Eugeniu Rosca <erosca@...adit-jv.com> wrote:
>
> Hello,
>
> On Thu, Jun 03, 2021 at 12:15:07PM -0500, Andrew Gabbasov wrote:
> > FunctionFS device structure 'struct ffs_dev' and driver data structure
> > 'struct ffs_data' are bound to each other with cross-reference pointers
> > 'ffs_data->private_data' and 'ffs_dev->ffs_data'. While the first one
> > is supposed to be valid through the whole life of 'struct ffs_data'
> > (and while 'struct ffs_dev' exists non-freed), the second one is cleared
> > in 'ffs_closed()' (called from 'ffs_data_reset()' or the last
> > 'ffs_data_put()'). This can be called several times, alternating in
> > different order with 'ffs_free_inst()', that, if possible, clears
> > the other cross-reference.
> >
[Skip some comment...]
> I confirm there are at least two KASAN use-after-free issues
> consistently/100% reproducible on v5.13-rc4-88-gf88cd3fb9df2:
>
> https://gist.github.com/erosca/b5976a96789e574b319cb9e076938b5c
> https://gist.github.com/erosca/4ded55ed32f0133bc2f4ccfe821c7776
>
> These two can no longer be seen after the patch is applied.
>
> In addition, below static analysis tools did not spot any regressions:
> cppcheck 2.4, smatch v0.5.0-7445-g58776ae33ae8, make W=1, coccicheck
>
> Reviewed-by: Eugeniu Rosca <erosca@...adit-jv.com>
> Tested-by: Eugeniu Rosca <erosca@...adit-jv.com>
>
> --
> Best regards,
> Eugeniu Rosca
It like there is similar issue on kernel-4.14 reported by our customer
(Android).
The back trace are similar.
It looks like this patch has fixed issue existed in earlier kernels.
Could Engeniu and Andrew help to comment if this fix is suggested to be pick to
stable-tree? I've tried to port it onto kernel-4.14, kernel-4.19, and
kernel-5.10.
But it seems there is some revise work to do.
If the origin issue affect multiple LTS kernel versions, then it will
be better to be
cherry-pick to stable-tree after it has been merged.
Thanks!
--
Best regards,
Macpaul Lin
Powered by blists - more mailing lists