> -----Original Message----- > From: Macpaul Lin <macpaul@xxxxxxxxx> > Sent: Friday, July 02, 2021 6:02 PM > To: Eugeniu Rosca <erosca@xxxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Felipe Balbi <balbi@xxxxxxxxxx>; Gabbasov, Andrew > <Andrew_Gabbasov@xxxxxxxxxx>; linux-usb@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Eugeniu Rosca > <roscaeugeniu@xxxxxxxxx>; Macpaul Lin <macpaul.lin@xxxxxxxxxxxx>; Eddie Hung <eddie.hung@xxxxxxxxxxxx> > Subject: Re: [PATCH] usb: gadget: f_fs: Fix setting of device and driver data cross-references > > Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> > > Tested-by: Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> > > > > -- > > 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 Hello! Originally this issue was discovered exactly in v4.14 (non-Android), and the fix was developed for that version and later forward-ported to latest mainline 5.13. So, indeed, it makes sense to apply the fix to stable versions (after it has been merged to mainline). I'm submitting the same patch, back-ported to stable/linux-4.14.y. It can also be applied to linux-4.19.y. While original 5.13 fix is applicable to linux-5.10.y. Thanks! Best regards, Andrew Gabbasov
