1. 02 Aug, 2010 2 commits
  2. 27 Jun, 2010 1 commit
  3. 27 May, 2010 2 commits
  4. 25 May, 2010 1 commit
  5. 21 May, 2010 2 commits
  6. 17 May, 2010 1 commit
  7. 16 May, 2010 4 commits
  8. 14 May, 2010 1 commit
  9. 10 May, 2010 1 commit
  10. 06 May, 2010 5 commits
  11. 05 May, 2010 7 commits
    • Tetsuo Handa's avatar
      TOMOYO: Use GFP_NOFS rather than GFP_KERNEL. · 4e5d6f7e
      Tetsuo Handa authored
      
      
      In Ubuntu, security_path_*() hooks are exported to Unionfs. Thus, prepare for
      being called from inside VFS functions because I'm not sure whether it is safe
      to use GFP_KERNEL or not.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      4e5d6f7e
    • David Howells's avatar
      KEYS: call_sbin_request_key() must write lock keyrings before modifying them · 896903c2
      David Howells authored
      
      
      call_sbin_request_key() creates a keyring and then attempts to insert a link to
      the authorisation key into that keyring, but does so without holding a write
      lock on the keyring semaphore.
      
      It will normally get away with this because it hasn't told anyone that the
      keyring exists yet.  The new keyring, however, has had its serial number
      published, which means it can be accessed directly by that handle.
      
      This was found by a previous patch that adds RCU lockdep checks to the code
      that reads the keyring payload pointer, which includes a check that the keyring
      semaphore is actually locked.
      
      Without this patch, the following command:
      
      	keyctl request2 user b a @s
      
      will provoke the following lockdep warning is displayed in dmesg:
      
      	===================================================
      	[ INFO: suspicious rcu_dereference_check() usage. ]
      	---------------------------------------------------
      	security/keys/keyring.c:727 invoked rcu_dereference_check() without protection!
      
      	other info that might help us debug this:
      
      	rcu_scheduler_active = 1, debug_locks = 0
      	2 locks held by keyctl/2076:
      	 #0:  (key_types_sem){.+.+.+}, at: [<ffffffff811a5b29>] key_type_lookup+0x1c/0x71
      	 #1:  (keyring_serialise_link_sem){+.+.+.}, at: [<ffffffff811a6d1e>] __key_link+0x4d/0x3c5
      
      	stack backtrace:
      	Pid: 2076, comm: keyctl Not tainted 2.6.34-rc6-cachefs #54
      	Call Trace:
      	 [<ffffffff81051fdc>] lockdep_rcu_dereference+0xaa/0xb2
      	 [<ffffffff811a6d1e>] ? __key_link+0x4d/0x3c5
      	 [<ffffffff811a6e6f>] __key_link+0x19e/0x3c5
      	 [<ffffffff811a5952>] ? __key_instantiate_and_link+0xb1/0xdc
      	 [<ffffffff811a59bf>] ? key_instantiate_and_link+0x42/0x5f
      	 [<ffffffff811aa0dc>] call_sbin_request_key+0xe7/0x33b
      	 [<ffffffff8139376a>] ? mutex_unlock+0x9/0xb
      	 [<ffffffff811a5952>] ? __key_instantiate_and_link+0xb1/0xdc
      	 [<ffffffff811a59bf>] ? key_instantiate_and_link+0x42/0x5f
      	 [<ffffffff811aa6fa>] ? request_key_auth_new+0x1c2/0x23c
      	 [<ffffffff810aaf15>] ? cache_alloc_debugcheck_after+0x108/0x173
      	 [<ffffffff811a9d00>] ? request_key_and_link+0x146/0x300
      	 [<ffffffff810ac568>] ? kmem_cache_alloc+0xe1/0x118
      	 [<ffffffff811a9e45>] request_key_and_link+0x28b/0x300
      	 [<ffffffff811a89ac>] sys_request_key+0xf7/0x14a
      	 [<ffffffff81052c0b>] ? trace_hardirqs_on_caller+0x10c/0x130
      	 [<ffffffff81394fb9>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      	 [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      896903c2
    • David Howells's avatar
      KEYS: Use RCU dereference wrappers in keyring key type code · f0641cba
      David Howells authored
      
      
      The keyring key type code should use RCU dereference wrappers, even when it
      holds the keyring's key semaphore.
      Reported-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      f0641cba
    • Toshiyuki Okajima's avatar
      KEYS: find_keyring_by_name() can gain access to a freed keyring · cea7daa3
      Toshiyuki Okajima authored
      
      
      find_keyring_by_name() can gain access to a keyring that has had its reference
      count reduced to zero, and is thus ready to be freed.  This then allows the
      dead keyring to be brought back into use whilst it is being destroyed.
      
      The following timeline illustrates the process:
      
      |(cleaner)                           (user)
      |
      | free_user(user)                    sys_keyctl()
      |  |                                  |
      |  key_put(user->session_keyring)     keyctl_get_keyring_ID()
      |  ||	//=> keyring->usage = 0        |
      |  |schedule_work(&key_cleanup_task)   lookup_user_key()
      |  ||                                   |
      |  kmem_cache_free(,user)               |
      |  .                                    |[KEY_SPEC_USER_KEYRING]
      |  .                                    install_user_keyrings()
      |  .                                    ||
      | key_cleanup() [<= worker_thread()]    ||
      |  |                                    ||
      |  [spin_lock(&key_serial_lock)]        |[mutex_lock(&key_user_keyr..mutex)]
      |  |                                    ||
      |  atomic_read() == 0                   ||
      |  |{ rb_ease(&key->serial_node,) }     ||
      |  |                                    ||
      |  [spin_unlock(&key_serial_lock)]      |find_keyring_by_name()
      |  |                                    |||
      |  keyring_destroy(keyring)             ||[read_lock(&keyring_name_lock)]
      |  ||                                   |||
      |  |[write_lock(&keyring_name_lock)]    ||atomic_inc(&keyring->usage)
      |  |.                                   ||| *** GET freeing keyring ***
      |  |.                                   ||[read_unlock(&keyring_name_lock)]
      |  ||                                   ||
      |  |list_del()                          |[mutex_unlock(&key_user_k..mutex)]
      |  ||                                   |
      |  |[write_unlock(&keyring_name_lock)]  ** INVALID keyring is returned **
      |  |                                    .
      |  kmem_cache_free(,keyring)            .
      |                                       .
      |                                       atomic_dec(&keyring->usage)
      v                                         *** DESTROYED ***
      TIME
      
      If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
      
      	=============================================================================
      	BUG key_jar: Poison overwritten
      	-----------------------------------------------------------------------------
      
      	INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
      	INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
      	INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
      	INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
      	INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
      
      	Bytes b4 0xffff880197a7e1f0:  5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
      	  Object 0xffff880197a7e200:  6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
      
      Alternatively, we may see a system panic happen, such as:
      
      	BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
      	IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
      	PGD 6b2b4067 PUD 6a80d067 PMD 0
      	Oops: 0000 [#1] SMP
      	last sysfs file: /sys/kernel/kexec_crash_loaded
      	CPU 1
      	...
      	Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
      	RIP: 0010:[<ffffffff810e61a3>]  [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
      	RSP: 0018:ffff88006af3bd98  EFLAGS: 00010002
      	RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b
      	RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430
      	RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000
      	R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0
      	R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce
      	FS:  00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0
      	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      	Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0)
      	Stack:
      	 0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
      	 0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
      	 0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
      	Call Trace:
      	 [<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f
      	 [<ffffffff810face3>] ? do_filp_open+0x145/0x590
      	 [<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33
      	 [<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2
      	 [<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d
      	 [<ffffffff81103916>] ? alloc_fd+0x69/0x10e
      	 [<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc
      	 [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
      	Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
      	RIP  [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
      
      This problem is that find_keyring_by_name does not confirm that the keyring is
      valid before accepting it.
      
      Skipping keyrings that have been reduced to a zero count seems the way to go.
      To this end, use atomic_inc_not_zero() to increment the usage count and skip
      the candidate keyring if that returns false.
      
      The following script _may_ cause the bug to happen, but there's no guarantee
      as the window of opportunity is small:
      
      	#!/bin/sh
      	LOOP=100000
      	USER=dummy_user
      	/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
      	for ((i=0; i<LOOP; i++))
      	do
      		/bin/su -c "echo '$i' > /dev/null" $USER
      	done
      	(( add == 1 )) && /usr/sbin/userdel -r $USER
      	exit
      
      Note that the nominated user must not be in use.
      
      An alternative way of testing this may be:
      
      	for ((i=0; i<100000; i++))
      	do
      		keyctl session foo /bin/true || break
      	done >&/dev/null
      
      as that uses a keyring named "foo" rather than relying on the user and
      user-session named keyrings.
      Reported-by: default avatarToshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarToshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      cea7daa3
    • David Howells's avatar
      KEYS: Fix RCU handling in key_gc_keyring() · cf8304e8
      David Howells authored
      key_gc_keyring() needs to either hold the RCU read lock or hold the keyring
      semaphore if it's going to scan the keyring's list.  Given that it only needs
      to read the key list, and it's doing so under a spinlock, the RCU read lock is
      the thing to use.
      
      Furthermore, the RCU check added in e7b0a61b
      
       is
      incorrect as holding the spinlock on key_serial_lock is not grounds for
      assuming a keyring's pointer list can be read safely.  Instead, a simple
      rcu_dereference() inside of the previously mentioned RCU read lock is what we
      want.
      Reported-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Acked-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      cf8304e8
    • David Howells's avatar
      KEYS: Fix an RCU warning in the reading of user keys · d9a9b4ae
      David Howells authored
      
      
      Fix an RCU warning in the reading of user keys:
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      security/keys/user_defined.c:202 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      1 lock held by keyctl/3637:
       #0:  (&key->sem){+++++.}, at: [<ffffffff811a80ae>] keyctl_read_key+0x9c/0xcf
      
      stack backtrace:
      Pid: 3637, comm: keyctl Not tainted 2.6.34-rc5-cachefs #18
      Call Trace:
       [<ffffffff81051f6c>] lockdep_rcu_dereference+0xaa/0xb2
       [<ffffffff811aa55f>] user_read+0x47/0x91
       [<ffffffff811a80be>] keyctl_read_key+0xac/0xcf
       [<ffffffff811a8a06>] sys_keyctl+0x75/0xb7
       [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      d9a9b4ae
    • Mimi Zohar's avatar
      ima: remove ACPI dependency · a674fa46
      Mimi Zohar authored
      The ACPI dependency moved to the TPM, where it belongs.  Although
      IMA per-se does not require access to the bios measurement log,
      verifying the IMA boot aggregate does, which requires ACPI.
      
      This patch prereq's 'TPM: ACPI/PNP dependency removal'
      http://lkml.org/lkml/2010/5/4/378
      
      .
      Signed-off-by: default avatarMimi Zohar <zohar@us.ibm.com>
      Reported-by: default avatarJean-Christophe Dubois <jcd@tribudubois.net>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Tested-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      a674fa46
  12. 04 May, 2010 2 commits
    • David Howells's avatar
      KEYS: Fix an RCU warning in the reading of user keys · e35ec2d2
      David Howells authored
      
      
      Fix an RCU warning in the reading of user keys:
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      security/keys/user_defined.c:202 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      1 lock held by keyctl/3637:
       #0:  (&key->sem){+++++.}, at: [<ffffffff811a80ae>] keyctl_read_key+0x9c/0xcf
      
      stack backtrace:
      Pid: 3637, comm: keyctl Not tainted 2.6.34-rc5-cachefs #18
      Call Trace:
       [<ffffffff81051f6c>] lockdep_rcu_dereference+0xaa/0xb2
       [<ffffffff811aa55f>] user_read+0x47/0x91
       [<ffffffff811a80be>] keyctl_read_key+0xac/0xcf
       [<ffffffff811a8a06>] sys_keyctl+0x75/0xb7
       [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      e35ec2d2
    • David Howells's avatar
      KEYS: Fix an RCU warning · bfeb0360
      David Howells authored
      
      
      Fix the following RCU warning:
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      security/keys/request_key.c:116 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      1 lock held by keyctl/5372:
       #0:  (key_types_sem){.+.+.+}, at: [<ffffffff811a4e3d>] key_type_lookup+0x1c/0x70
      
      stack backtrace:
      Pid: 5372, comm: keyctl Not tainted 2.6.34-rc3-cachefs #150
      Call Trace:
       [<ffffffff810515f8>] lockdep_rcu_dereference+0xaa/0xb2
       [<ffffffff811a9220>] call_sbin_request_key+0x156/0x2b6
       [<ffffffff811a4c66>] ? __key_instantiate_and_link+0xb1/0xdc
       [<ffffffff811a4cd3>] ? key_instantiate_and_link+0x42/0x5f
       [<ffffffff811a96b8>] ? request_key_auth_new+0x17b/0x1f3
       [<ffffffff811a8e00>] ? request_key_and_link+0x271/0x400
       [<ffffffff810aba6f>] ? kmem_cache_alloc+0xe1/0x118
       [<ffffffff811a8f1a>] request_key_and_link+0x38b/0x400
       [<ffffffff811a7b72>] sys_request_key+0xf7/0x14a
       [<ffffffff81052227>] ? trace_hardirqs_on_caller+0x10c/0x130
       [<ffffffff81393f5c>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
      
      This was caused by doing:
      
      	[root@andromeda ~]# keyctl newring fred @s
      	539196288
      	[root@andromeda ~]# keyctl request2 user a a 539196288
      	request_key: Required key not available
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      bfeb0360
  13. 28 Apr, 2010 1 commit
    • Stephen Smalley's avatar
      selinux: generalize disabling of execmem for plt-in-heap archs · fcaaade1
      Stephen Smalley authored
      
      
      On Tue, 2010-04-27 at 11:47 -0700, David Miller wrote:
      > From: "Tom \"spot\" Callaway" <tcallawa@redhat.com>
      > Date: Tue, 27 Apr 2010 14:20:21 -0400
      >
      > > [root@apollo ~]$ cat /proc/2174/maps
      > > 00010000-00014000 r-xp 00000000 fd:00 15466577
      > >  /sbin/mingetty
      > > 00022000-00024000 rwxp 00002000 fd:00 15466577
      > >  /sbin/mingetty
      > > 00024000-00046000 rwxp 00000000 00:00 0
      > >  [heap]
      >
      > SELINUX probably barfs on the executable heap, the PLT is in the HEAP
      > just like powerpc32 and that's why VM_DATA_DEFAULT_FLAGS has to set
      > both executable and writable.
      >
      > You also can't remove the CONFIG_PPC32 ifdefs in selinux, since
      > because of the VM_DATA_DEFAULT_FLAGS setting used still in that arch,
      > the heap will always have executable permission, just like sparc does.
      > You have to support those binaries forever, whether you like it or not.
      >
      > Let's just replace the CONFIG_PPC32 ifdef in SELINUX with CONFIG_PPC32
      > || CONFIG_SPARC as in Tom's original patch and let's be done with
      > this.
      >
      > In fact I would go through all the arch/ header files and check the
      > VM_DATA_DEFAULT_FLAGS settings and add the necessary new ifdefs to the
      > SELINUX code so that other platforms don't have the pain of having to
      > go through this process too.
      
      To avoid maintaining per-arch ifdefs, it seems that we could just
      directly use (VM_DATA_DEFAULT_FLAGS & VM_EXEC) as the basis for deciding
      whether to enable or disable these checks.   VM_DATA_DEFAULT_FLAGS isn't
      constant on some architectures but instead depends on
      current->personality, but we want this applied uniformly.  So we'll just
      use the initial task state to determine whether or not to enable these
      checks.
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      fcaaade1
  14. 27 Apr, 2010 3 commits
    • David Howells's avatar
      keys: the request_key() syscall should link an existing key to the dest keyring · 03449cd9
      David Howells authored
      
      
      The request_key() system call and request_key_and_link() should make a
      link from an existing key to the destination keyring (if supplied), not
      just from a new key to the destination keyring.
      
      This can be tested by:
      
      	ring=`keyctl newring fred @s`
      	keyctl request2 user debug:a a
      	keyctl request user debug:a $ring
      	keyctl list $ring
      
      If it says:
      
      	keyring is empty
      
      then it didn't work.  If it shows something like:
      
      	1 key in keyring:
      	1070462727: --alswrv     0     0 user: debug:a
      
      then it did.
      
      request_key() system call is meant to recursively search all your keyrings for
      the key you desire, and, optionally, if it doesn't exist, call out to userspace
      to create one for you.
      
      If request_key() finds or creates a key, it should, optionally, create a link
      to that key from the destination keyring specified.
      
      Therefore, if, after a successful call to request_key() with a desination
      keyring specified, you see the destination keyring empty, the code didn't work
      correctly.
      
      If you see the found key in the keyring, then it did - which is what the patch
      is required for.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      03449cd9
    • Eric Paris's avatar
      LSM Audit: rename LSM_AUDIT_NO_AUDIT to LSM_AUDIT_DATA_NONE · cb84aa9b
      Eric Paris authored
      
      
      Most of the LSM common audit work uses LSM_AUDIT_DATA_* for the naming.
      This was not so for LSM_AUDIT_NO_AUDIT which means the generic initializer
      cannot be used.  This patch just renames the flag so the generic
      initializer can be used.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      cb84aa9b
    • David Howells's avatar
      keys: don't need to use RCU in keyring_read() as semaphore is held · b59ec78c
      David Howells authored
      
      
      keyring_read() doesn't need to use rcu_dereference() to access the keyring
      payload as the caller holds the key semaphore to prevent modifications
      from happening whilst the data is read out.
      
      This should solve the following warning:
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      security/keys/keyring.c:204 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      1 lock held by keyctl/2144:
       #0:  (&key->sem){+++++.}, at: [<ffffffff81177f7c>] keyctl_read_key+0x9c/0xcf
      
      stack backtrace:
      Pid: 2144, comm: keyctl Not tainted 2.6.34-rc2-cachefs #113
      Call Trace:
       [<ffffffff8105121f>] lockdep_rcu_dereference+0xaa/0xb2
       [<ffffffff811762d5>] keyring_read+0x4d/0xe7
       [<ffffffff81177f8c>] keyctl_read_key+0xac/0xcf
       [<ffffffff811788d4>] sys_keyctl+0x75/0xb9
       [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      b59ec78c
  15. 26 Apr, 2010 1 commit
  16. 24 Apr, 2010 1 commit
  17. 23 Apr, 2010 1 commit
  18. 22 Apr, 2010 3 commits
  19. 20 Apr, 2010 1 commit