[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ef330bdbf0e0a176a2e5c32121e86dc2c46934b6.camel@linux.ibm.com>
Date: Tue, 14 Mar 2023 20:17:02 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Roman Danilov <romanosauce57@...il.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
Paul Moore <paul@...l-moore.com>,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Roberto Sassu <roberto.sassu@...wei.com>,
GUO Zihua <guozihua@...wei.com>,
linux-integrity@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, lvc-project@...uxtesting.org,
Alexey Khoroshilov <khoroshilov@...ras.ru>
Subject: Re: [PATCH] ima: Fix potential NULL pointer access in
ima_match_rules()
On Tue, 2023-03-14 at 21:03 +0300, Roman Danilov wrote:
> In ima_match_rules(), when ima_lsm_copy_rule() fails, NULL pointer
> is assigned to lsm_rule. After that, in the next step of the loop
> NULL pointer is dereferenced in lsm_rule->lsm[i].rule.
I must being missing something. The next step of the loop tests
whether rule_reinitialized is set before accessing lsm_rule-
>lsm[i].rule.
>
> As far as ima_match_rules() is not designed to return error code,
> add __GFP_NOFAIL to make sure memory allocation succeeds.
Using __GFP_NOFAIL here would be safer.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()")
> Signed-off-by: Roman Danilov <romanosauce57@...il.com>
> Reviewed-by: Alexey Khoroshilov <khoroshilov@...ras.ru>
--
thanks,
Mimi
Powered by blists - more mailing lists