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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022/12/9 17:22, Greg KH wrote:
> 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@xxxxxxxxxx/
>>>>>>>>
>>>>>>>> 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.
Alright. We'll wait for these patches to be in Linus' tree. But should
we stick to a backport from mainstream or we form a different solution
for LTS?

-- 
Best
GUO Zihua




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux