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.
The commit which introduced the issue on mainline was believed to be
b16942455193 ("ima: use the lsm policy update notifier"), which is not in
4.19.y. And the mainline patch is designed to handle the situation when IMA
rules are accessed through RCU which has not been implemented on 4.19.y
either.
Ok, then provide a series of backports to 4.19 and we will be glad to
review them.
If we are backporting these commits to 4.19 then maybe we would have to
start with the commit that makes rule access in IMA RCU protected. I'll
have a look into whether it's easy to do.
thanks,
greg k-h
--
Best
GUO Zihua