On Tue, 2024-05-07 at 09:37 +0000, GUO Zihua wrote:
> From: liqiong <liqi...@nfschina.com>
> 
> [ Upstream commit eb0782bbdfd0d7c4786216659277c3fd585afc0e ]
> 
> The current IMA ruleset is identified by the variable "ima_rules"
> that default to "&ima_default_rules". When loading a custom policy
> for the first time, the variable is updated to "&ima_policy_rules"
> instead. That update isn't RCU-safe, and deadlocks are possible.
> Indeed, some functions like ima_match_policy() may loop indefinitely
> when traversing "ima_default_rules" with list_for_each_entry_rcu().
> 
> When iterating over the default ruleset back to head, if the list
> head is "ima_default_rules", and "ima_rules" have been updated to
> "&ima_policy_rules", the loop condition (&entry->list != ima_rules)
> stays always true, traversing won't terminate, causing a soft lockup
> and RCU stalls.
> 
> Introduce a temporary value for "ima_rules" when iterating over
> the ruleset to avoid the deadlocks.
> 
> Addition:
> 
> A rcu_read_lock pair is added within ima_update_policy_flag to avoid
> suspicious RCU usage warning. This pair of RCU lock was added with
> commit 4f2946aa0c45 ("IMA: introduce a new policy option
> func=SETXATTR_CHECK") on mainstream.
> 
> Signed-off-by: liqiong <liqi...@nfschina.com>
> Reviewed-by: THOBY Simon <simon.th...@viveris.fr>
> Fixes: 38d859f991f3 ("IMA: policy can now be updated multiple times")
> Reported-by: kernel test robot <l...@intel.com> (Fix sparse: incompatible 
> types in comparison expression.)
> Signed-off-by: Mimi Zohar <zo...@linux.ibm.com>
> Sig=ned-off-by: GUO Zihua <guozi...@huawei.com>

Hi Scott,

I'm confused by this patch.  Is it meant for upstream?

thanks,

Mimi


Reply via email to