linux-toradex.git/security/keys, branch v2.6.35.7

KEYS: Fix bug in keyctl_session_to_parent() if parent has no session keyring

2010-09-27T00:18:36+00:00

commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376 upstream.

Fix a bug in keyctl_session_to_parent() whereby it tries to check the ownership
of the parent process's session keyring whether or not the parent has a session
keyring [CVE-2010-2960].

This results in the following oops:

  BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
  IP: [] keyctl_session_to_parent+0x251/0x443
  ...
  Call Trace:
   [] ? keyctl_session_to_parent+0x67/0x443
   [] ? __do_fault+0x24b/0x3d0
   [] sys_keyctl+0xb4/0xb8
   [] system_call_fastpath+0x16/0x1b

if the parent process has no session keyring.

If the system is using pam_keyinit then it mostly protected against this as all
processes derived from a login will have inherited the session keyring created
by pam_keyinit during the log in procedure.

To test this, pam_keyinit calls need to be commented out in /etc/pam.d/.

Reported-by: Tavis Ormandy 
Signed-off-by: David Howells 
Acked-by: Tavis Ormandy 
Cc: dann frazier 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

KEYS: Fix RCU no-lock warning in keyctl_session_to_parent()

2010-09-27T00:18:35+00:00

commit 9d1ac65a9698513d00e5608d93fca0c53f536c14 upstream.

There's an protected access to the parent process's credentials in the middle
of keyctl_session_to_parent().  This results in the following RCU warning:

  ===================================================
  [ INFO: suspicious rcu_dereference_check() usage. ]
  ---------------------------------------------------
  security/keys/keyctl.c:1291 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-session-/2137:
   #0:  (tasklist_lock){.+.+..}, at: [] keyctl_session_to_parent+0x60/0x236

  stack backtrace:
  Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1
  Call Trace:
   [] lockdep_rcu_dereference+0xaa/0xb3
   [] keyctl_session_to_parent+0xed/0x236
   [] sys_keyctl+0xb4/0xb6
   [] system_call_fastpath+0x16/0x1b

The code should take the RCU read lock to make sure the parents credentials
don't go away, even though it's holding a spinlock and has IRQ disabled.

Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds 
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman

KEYS: Propagate error code instead of returning -EINVAL

2010-06-27T14:02:34+00:00

This is from a Smatch check I'm writing.

strncpy_from_user() returns -EFAULT on error so the first change just
silences a warning but doesn't change how the code works.

The other change is a bug fix because install_thread_keyring_to_cred()
can return a variety of errors such as -EINVAL, -EEXIST, -ENOMEM or
-EKEYREVOKED.

Signed-off-by: Dan Carpenter 
Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds

keyctl_session_to_parent(): use thread_group_empty() to check singlethreadness

2010-05-27T16:12:47+00:00

No functional changes.

keyctl_session_to_parent() is the only user of signal->count which needs
the correct value.  Change it to use thread_group_empty() instead, this
must be strictly equivalent under tasklist, and imho looks better.

Signed-off-by: Oleg Nesterov 
Acked-by: David Howells 
Cc: Peter Zijlstra 
Acked-by: Roland McGrath 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

umh: creds: convert call_usermodehelper_keys() to use subprocess_info->init()

2010-05-27T16:12:45+00:00

call_usermodehelper_keys() uses call_usermodehelper_setkeys() to change
subprocess_info->cred in advance.  Now that we have info->init() we can
change this code to set tgcred->session_keyring in context of execing
kernel thread.

Note: since currently call_usermodehelper_keys() is never called with
UMH_NO_WAIT, call_usermodehelper_keys()->key_get() and umh_keys_cleanup()
are not really needed, we could rely on install_session_keyring_to_cred()
which does key_get() on success.

Signed-off-by: Oleg Nesterov 
Acked-by: Neil Horman 
Acked-by: David Howells 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kernel-wide: replace USHORT_MAX, SHORT_MAX and SHORT_MIN with USHRT_MAX, SHRT_MAX and SHRT_MIN

2010-05-25T15:07:02+00:00

- C99 knows about USHRT_MAX/SHRT_MAX/SHRT_MIN, not
  USHORT_MAX/SHORT_MAX/SHORT_MIN.

- Make SHRT_MIN of type s16, not int, for consistency.

[akpm@linux-foundation.org: fix drivers/dma/timb_dma.c]
[akpm@linux-foundation.org: fix security/keys/keyring.c]
Signed-off-by: Alexey Dobriyan 
Acked-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

KEYS: Return more accurate error codes

2010-05-17T22:50:55+00:00

We were using the wrong variable here so the error codes weren't being returned
properly.  The original code returns -ENOKEY.

Signed-off-by: Dan Carpenter 
Signed-off-by: David Howells 
Signed-off-by: James Morris

KEYS: Do preallocation for __key_link()

2010-05-06T12:25:02+00:00

Do preallocation for __key_link() so that the various callers in request_key.c
can deal with any errors from this source before attempting to construct a key.
This allows them to assume that the actual linkage step is guaranteed to be
successful.

Signed-off-by: David Howells 
Signed-off-by: James Morris

Merge branch 'master' into next

2010-05-06T12:21:04+00:00

Conflicts:
	security/keys/keyring.c

Resolved conflict with whitespace fix in find_keyring_by_name()

Signed-off-by: James Morris

KEYS: Better handling of errors from construct_alloc_key()

2010-05-06T00:56:55+00:00

Errors from construct_alloc_key() shouldn't just be ignored in the way they are
by construct_key_and_link().  The only error that can be ignored so is
EINPROGRESS as that is used to indicate that we've found a key and don't need
to construct one.

We don't, however, handle ENOMEM, EDQUOT or EACCES to indicate allocation
failures of one sort or another.

Reported-by: Vegard Nossum 
Signed-off-by: David Howells 
Signed-off-by: James Morris