Re: [RFC] IMA LSM based rule race condition issue on 4.19 LTS

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Dec 09, 2022 at 05:11:40PM +0800, Guozihua (Scott) wrote:
> On 2022/12/9 17:00, Greg KH wrote:
> > On Fri, Dec 09, 2022 at 04:59:17PM +0800, Guozihua (Scott) wrote:
> >> On 2022/12/9 16:46, Greg KH wrote:
> >>> On Fri, Dec 09, 2022 at 03:53:25PM +0800, Guozihua (Scott) wrote:
> >>>> On 2022/12/9 15:12, Greg KH wrote:
> >>>>> On Fri, Dec 09, 2022 at 03:00:35PM +0800, Guozihua (Scott) wrote:
> >>>>>> Hi community.
> >>>>>>
> >>>>>> Previously our team reported a race condition in IMA relates to LSM based
> >>>>>> rules which would case IMA to match files that should be filtered out under
> >>>>>> normal condition. The issue was originally analyzed and fixed on mainstream.
> >>>>>> The patch and the discussion could be found here:
> >>>>>> https://lore.kernel.org/all/20220921125804.59490-1-guozihua@huawei.com/
> >>>>>>
> >>>>>> After that, we did a regression test on 4.19 LTS and the same issue arises.
> >>>>>> Further analysis reveled that the issue is from a completely different
> >>>>>> cause.
> >>>>>
> >>>>> What commit in the tree fixed this in newer kernels?  Why can't we just
> >>>>> backport that one to 4.19.y as well?
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> greg k-h
> >>>>
> >>>> Hi Greg,
> >>>>
> >>>> The fix for mainline is now on linux-next, commit 	d57378d3aa4d ("ima:
> >>>> Simplify ima_lsm_copy_rule") and 	c7423dbdbc9ece ("ima: Handle -ESTALE
> >>>> returned by ima_filter_rule_match()"). However, these patches cannot be
> >>>> picked directly into 4.19.y due to code difference.
> >>>
> >>> Ok, so it's much more than just 4.19 that's an issue here.  And are
> >>> those commits tagged for stable inclusion?
> >>
> >> Not actually, not on the commit itself.
> > 
> > That's not good.  When they hit Linus's tree, please submit backports to
> > the stable mailing list so that they can be picked up.
> Thing is these commits cannot be simply backported to 4.19.y. Preceding
> patches are missing. How do we do backporting in this situation? Do we
> first backport the preceding patches? Or maybe we develop another
> solution for 4.19.y?

First they need to go to newer kernel trees, and then worry about 4.19.
We never want anyone to upgrade to a newer kernel and have a regression.

Also, we can't do anything until they hit Linus's tree, as per the
stable kernel rules.

thanks,

greg k-h