linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Paul Moore <paul@paul-moore.com>, GUO Zihua <guozihua@huawei.com>,
	 john.johansen@canonical.com, jmorris@namei.org,
	serge@hallyn.com,  zohar@linux.ibm.com, roberto.sassu@huawei.com,
	dmitry.kasatkin@gmail.com,  stephen.smalley.work@gmail.com,
	casey@schaufler-ca.com, eparis@redhat.com
Cc: eric.snowberg@oracle.com, omosnace@redhat.com,
	audit@vger.kernel.org,  apparmor@lists.ubuntu.com,
	linux-security-module@vger.kernel.org,
	 linux-integrity@vger.kernel.org, selinux@vger.kernel.org
Subject: Re: [PATCH v3] ima: Avoid blocking in RCU read-side critical section
Date: Fri, 14 Jun 2024 11:50:18 +0200	[thread overview]
Message-ID: <8e898e2f5ae479ab08be61048481404d12cb6ea4.camel@huaweicloud.com> (raw)
In-Reply-To: <CAHC9VhRqvBsdy+U-wr+X6QmawLv6DnB32nwAO7Ex6L7cdR=mSg@mail.gmail.com>

On Thu, 2024-06-13 at 14:26 -0400, Paul Moore wrote:
> On Wed, Jun 12, 2024 at 5:43 PM Paul Moore <paul@paul-moore.com> wrote:
> > On May  6, 2024 GUO Zihua <guozihua@huawei.com> wrote:
> > > 
> > > A panic happens in ima_match_policy:
> > > 
> > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> > > PGD 42f873067 P4D 0
> > > Oops: 0000 [#1] SMP NOPTI
> > > CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: loaded Tainted: P
> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
> > > RIP: 0010:ima_match_policy+0x84/0x450
> > > Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f
> > > RSP: 0018:ff71570009e07a80 EFLAGS: 00010207
> > > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200
> > > RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000
> > > RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739
> > > R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970
> > > R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001
> > > FS:  00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000
> > > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0
> > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > Call Trace:
> > >  ima_get_action+0x22/0x30
> > >  process_measurement+0xb0/0x830
> > >  ? page_add_file_rmap+0x15/0x170
> > >  ? alloc_set_pte+0x269/0x4c0
> > >  ? prep_new_page+0x81/0x140
> > >  ? simple_xattr_get+0x75/0xa0
> > >  ? selinux_file_open+0x9d/0xf0
> > >  ima_file_check+0x64/0x90
> > >  path_openat+0x571/0x1720
> > >  do_filp_open+0x9b/0x110
> > >  ? page_counter_try_charge+0x57/0xc0
> > >  ? files_cgroup_alloc_fd+0x38/0x60
> > >  ? __alloc_fd+0xd4/0x250
> > >  ? do_sys_open+0x1bd/0x250
> > >  do_sys_open+0x1bd/0x250
> > >  do_syscall_64+0x5d/0x1d0
> > >  entry_SYSCALL_64_after_hwframe+0x65/0xca
> > > 
> > > Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by
> > > ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a
> > > RCU read-side critical section which contains kmalloc with GFP_KERNEL.
> > > This implies a possible sleep and violates limitations of RCU read-side
> > > critical sections on non-PREEMPT systems.
> > > 
> > > Sleeping within RCU read-side critical section might cause
> > > synchronize_rcu() returning early and break RCU protection, allowing a
> > > UAF to happen.
> > > 
> > > The root cause of this issue could be described as follows:
> > > >     Thread A        |       Thread B        |
> > > >                     |ima_match_policy       |
> > > >                     |  rcu_read_lock        |
> > > > ima_lsm_update_rule  |                       |
> > > >  synchronize_rcu    |                       |
> > > >                     |    kmalloc(GFP_KERNEL)|
> > > >                     |      sleep            |
> > > ==> synchronize_rcu returns early
> > > >  kfree(entry)               |                       |
> > > >                     |    entry = entry->next|
> > > ==> UAF happens and entry now becomes NULL (or could be anything).
> > > >                     |    entry->action      |
> > > ==> Accessing entry might cause panic.
> > > 
> > > To fix this issue, we are converting all kmalloc that is called within
> > > RCU read-side critical section to use GFP_ATOMIC.
> > > 
> > > Fixes: c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: GUO Zihua <guozihua@huawei.com>
> > > Acked-by: John Johansen <john.johansen@canonical.com>
> > > Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> > > Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> > > ---
> > > v3:
> > >   ima_lsm_copy_rule takes a GFP flag as input as well.
> > > v2:
> > >   Changed the audit_rule_init security hook to accept a new GFP flag, as
> > > per Stephen's suggestion.
> > > 
> > > ---
> > >  include/linux/lsm_hook_defs.h       |  2 +-
> > >  include/linux/security.h            |  5 +++--
> > >  kernel/auditfilter.c                |  5 +++--
> > >  security/apparmor/audit.c           |  6 +++---
> > >  security/apparmor/include/audit.h   |  2 +-
> > >  security/integrity/ima/ima_policy.c | 15 +++++++++------
> > >  security/security.c                 |  6 ++++--
> > >  security/selinux/include/audit.h    |  4 +++-
> > >  security/selinux/ss/services.c      |  5 +++--
> > >  security/smack/smack_lsm.c          |  3 ++-
> > >  10 files changed, 32 insertions(+), 21 deletions(-)
> > 
> > With the exception of one small gotcha (see below), this looks okay to
> > me.  At Mimi's request I'm going to merge this into the LSM tree, via
> > lsm/stable-6.10, where I'll give it a few days in linux-next before
> > sending it up to Linus.
> 
> I also had to apply the following fix to this patch to resolve the
> !CONFIG_IMA_LSM_RULES ca
> se ... grrrrr.

Argh, sorry...

Thanks Paul!

Roberto

> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index 3e568126cd48..c51e24d24d1e 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -546,7 +546,7 @@ static inline void ima_free_modsig(struct modsig *modsig)
> #else
> 
> static inline int ima_filter_rule_init(u32 field, u32 op, char *rulestr,
> -                                      void **lsmrule)
> +                                      void **lsmrule, gfp_t gfp)
> {
>        return -EINVAL;
> }
> 
> > > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> > > index 146667937811..a4943628d75a 100644
> > > --- a/security/smack/smack_lsm.c
> > > +++ b/security/smack/smack_lsm.c
> > > @@ -4696,7 +4696,8 @@ static int smack_post_notification(const struct cred *w_cred,
> > >   * Prepare to audit cases where (@field @op @rulestr) is true.
> > >   * The label to be audited is created if necessay.
> > >   */
> > > -static int smack_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule)
> > > +static int smack_audit_rule_init(u32 field, u32 op, char *rulestr, void **vrule,
> > > +                              gfp_t gfp)
> > 
> > You forgot to add the new @gfp parameter to the function's header
> > comment block.  I'm going to add the following as the text is used in
> > other Smack functions, if anyone has any objections please let me know.
> > 
> >   " * @gfp: type of the memory for the allocation"
> > 
> > >  {
> > >       struct smack_known *skp;
> > >       char **rule = (char **)vrule;
> 


  reply	other threads:[~2024-06-14 10:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07  1:25 [PATCH v3] ima: Avoid blocking in RCU read-side critical section GUO Zihua
2024-05-07 20:35 ` Mimi Zohar
2024-05-10 16:03 ` Casey Schaufler
2024-06-03 14:44   ` Mimi Zohar
2024-06-04 21:11 ` John Johansen
2024-06-12 21:43 ` Paul Moore
2024-06-13 18:26   ` Paul Moore
2024-06-14  9:50     ` Roberto Sassu [this message]
2024-06-14 15:23       ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8e898e2f5ae479ab08be61048481404d12cb6ea4.camel@huaweicloud.com \
    --to=roberto.sassu@huaweicloud.com \
    --cc=apparmor@lists.ubuntu.com \
    --cc=audit@vger.kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=eparis@redhat.com \
    --cc=eric.snowberg@oracle.com \
    --cc=guozihua@huawei.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=roberto.sassu@huawei.com \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=stephen.smalley.work@gmail.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).