On 2024/5/8 10:06, Guozihua (Scott) wrote:
> On 2024/5/7 19:54, Mimi Zohar wrote:
>> On Tue, 2024-05-07 at 09:37 +0000, GUO Zihua wrote:
>>> From: liqiong <liqiong@xxxxxxxxxxxx>
>>>
>>> [ 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 <liqiong@xxxxxxxxxxxx>
>>> Reviewed-by: THOBY Simon <Simon.THOBY@xxxxxxxxxx>
>>> Fixes: 38d859f991f3 ("IMA: policy can now be updated multiple times")
>>> Reported-by: kernel test robot <lkp@xxxxxxxxx> (Fix sparse: incompatible types in comparison expression.)
>>> Signed-off-by: Mimi Zohar <zohar@xxxxxxxxxxxxx>
>>> Sig=ned-off-by: GUO Zihua <guozihua@xxxxxxxxxx>
>>
>> Hi Scott,
>>
>> I'm confused by this patch. Is it meant for upstream?
>>
>> thanks,
>>
>> Mimi
>>
> It's a backport from upstream.
>
To clarify, it's meant for Linux-5.10.y.
--
Best
GUO Zihua
