From 21279cfa107af07ef985539ac0de2152b9cba5f5 Mon Sep 17 00:00:00 2001 From: David Howells Date: Thu, 15 Oct 2009 10:14:35 +0100 Subject: KEYS: get_instantiation_keyring() should inc the keyring refcount in all cases The destination keyring specified to request_key() and co. is made available to the process that instantiates the key (the slave process started by /sbin/request-key typically). This is passed in the request_key_auth struct as the dest_keyring member. keyctl_instantiate_key and keyctl_negate_key() call get_instantiation_keyring() to get the keyring to attach the newly constructed key to at the end of instantiation. This may be given a specific keyring into which a link will be made later, or it may be asked to find the keyring passed to request_key(). In the former case, it returns a keyring with the refcount incremented by lookup_user_key(); in the latter case, it returns the keyring from the request_key_auth struct - and does _not_ increment the refcount. The latter case will eventually result in an oops when the keyring prematurely runs out of references and gets destroyed. The effect may take some time to show up as the key is destroyed lazily. To fix this, the keyring returned by get_instantiation_keyring() must always have its refcount incremented, no matter where it comes from. This can be tested by setting /etc/request-key.conf to: #OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ... #====== ======= =============== =============== =============================== create * test:* * |/bin/false %u %g %d %{user:_display} negate * * * /bin/keyctl negate %k 10 @u and then doing: keyctl add user _display aaaaaaaa @u while keyctl request2 user test:x test:x @u && keyctl list @u; do keyctl request2 user test:x test:x @u; sleep 31; keyctl list @u; done which will oops eventually. Changing the negate line to have @u rather than %S at the end is important as that forces the latter case by passing a special keyring ID rather than an actual keyring ID. Reported-by: Alexander Zangerl Signed-off-by: David Howells Tested-by: Alexander Zangerl Signed-off-by: Linus Torvalds --- security/keys/keyctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'security') diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c index 2fb28efc5326..06ec722897be 100644 --- a/security/keys/keyctl.c +++ b/security/keys/keyctl.c @@ -873,7 +873,7 @@ static long get_instantiation_keyring(key_serial_t ringid, /* otherwise specify the destination keyring recorded in the * authorisation key (any KEY_SPEC_*_KEYRING) */ if (ringid >= KEY_SPEC_REQUESTOR_KEYRING) { - *_dest_keyring = rka->dest_keyring; + *_dest_keyring = key_get(rka->dest_keyring); return 0; } -- cgit v1.2.3 From c09c59e6a070d6af05f238f255aea268185273ef Mon Sep 17 00:00:00 2001 From: Mimi Zohar Date: Wed, 18 Nov 2009 16:16:06 -0500 Subject: ima: replace GFP_KERNEL with GFP_NOFS While running fsstress tests on the NFSv4 mounted ext3 and ext4 filesystem, the following call trace was generated on the nfs server machine. Replace GFP_KERNEL with GFP_NOFS in ima_iint_insert() to avoid a potential deadlock. ================================= [ INFO: inconsistent lock state ] 2.6.31-31.el6.x86_64 #1 --------------------------------- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. kswapd2/75 [HC0[0]:SC0[0]:HE1:SE1] takes: (jbd2_handle){+.+.?.}, at: [] jbd2_journal_start+0xfe/0x13f {RECLAIM_FS-ON-W} state was registered at: [] mark_held_locks+0x65/0x99 [] lockdep_trace_alloc+0xbd/0xf5 [] kmem_cache_alloc+0x40/0x185 [] ima_iint_insert+0x3d/0xf1 [] ima_inode_alloc+0x25/0x44 [] inode_init_always+0xec/0x271 [] alloc_inode+0x51/0xa1 [] new_inode+0x2e/0x94 [] ext4_new_inode+0xb8/0xdc9 [] ext4_create+0xcf/0x175 [] vfs_create+0x82/0xb8 [] do_filp_open+0x32c/0x9ee [] do_sys_open+0x6c/0x12c [] sys_open+0x2e/0x44 [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff irq event stamp: 90371 hardirqs last enabled at (90371): [] kmem_cache_alloc+0xf0/0x185 hardirqs last disabled at (90370): [] kmem_cache_alloc+0x89/0x185 softirqs last enabled at (89492): [] __do_softirq+0x1bf/0x1eb softirqs last disabled at (89477): [] call_softirq+0x1c/0x30 other info that might help us debug this: 2 locks held by kswapd2/75: #0: (shrinker_rwsem){++++..}, at: [] shrink_slab+0x44/0x177 #1: (&type->s_umount_key#25){++++..}, at: [] Reported-by: Muni P. Beerakam Reported-by: Amit K. Arora Cc: stable@kernel.org Signed-off-by: Mimi Zohar Signed-off-by: James Morris --- security/integrity/ima/ima_iint.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'security') diff --git a/security/integrity/ima/ima_iint.c b/security/integrity/ima/ima_iint.c index b8dd693f8790..a4e2b1dac943 100644 --- a/security/integrity/ima/ima_iint.c +++ b/security/integrity/ima/ima_iint.c @@ -58,11 +58,11 @@ struct ima_iint_cache *ima_iint_insert(struct inode *inode) if (!ima_initialized) return iint; - iint = kmem_cache_alloc(iint_cache, GFP_KERNEL); + iint = kmem_cache_alloc(iint_cache, GFP_NOFS); if (!iint) return iint; - rc = radix_tree_preload(GFP_KERNEL); + rc = radix_tree_preload(GFP_NOFS); if (rc < 0) goto out; -- cgit v1.2.3