linux-toradex.git/security/keys, branch v3.0.79

Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys

2013-03-28T19:06:04+00:00

commit 8aec0f5d4137532de14e6554fd5dd201ff3a3c49 upstream.

Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to
compat_process_vm_rw() shows that the compatibility code requires an
explicit "access_ok()" check before calling
compat_rw_copy_check_uvector(). The same difference seems to appear when
we compare fs/read_write.c:do_readv_writev() to
fs/compat.c:compat_do_readv_writev().

This subtle difference between the compat and non-compat requirements
should probably be debated, as it seems to be error-prone. In fact,
there are two others sites that use this function in the Linux kernel,
and they both seem to get it wrong:

Now shifting our attention to fs/aio.c, we see that aio_setup_iocb()
also ends up calling compat_rw_copy_check_uvector() through
aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to
be missing. Same situation for
security/keys/compat.c:compat_keyctl_instantiate_key_iov().

I propose that we add the access_ok() check directly into
compat_rw_copy_check_uvector(), so callers don't have to worry about it,
and it therefore makes the compat call code similar to its non-compat
counterpart. Place the access_ok() check in the same location where
copy_from_user() can trigger a -EFAULT error in the non-compat code, so
the ABI behaviors are alike on both compat and non-compat.

While we are here, fix compat_do_readv_writev() so it checks for
compat_rw_copy_check_uvector() negative return values.

And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error
handling.

Acked-by: Linus Torvalds 
Acked-by: Al Viro 
Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

key: Fix resource leak

2013-03-28T19:06:04+00:00

commit a84a921978b7d56e0e4b87ffaca6367429b4d8ff upstream.

On an error iov may still have been reallocated and need freeing

Signed-off-by: Alan Cox 
Signed-off-by: David Howells 
Signed-off-by: Greg Kroah-Hartman

keys: fix race with concurrent install_user_keyrings()

2013-03-14T18:32:06+00:00

commit 0da9dfdd2cd9889201bc6f6f43580c99165cd087 upstream.

This fixes CVE-2013-1792.

There is a race in install_user_keyrings() that can cause a NULL pointer
dereference when called concurrently for the same user if the uid and
uid-session keyrings are not yet created.  It might be possible for an
unprivileged user to trigger this by calling keyctl() from userspace in
parallel immediately after logging in.

Assume that we have two threads both executing lookup_user_key(), both
looking for KEY_SPEC_USER_SESSION_KEYRING.

	THREAD A			THREAD B
	===============================	===============================
					==>call install_user_keyrings();
	if (!cred->user->session_keyring)
	==>call install_user_keyrings()
					...
					user->uid_keyring = uid_keyring;
	if (user->uid_keyring)
		return 0;
	<==
	key = cred->user->session_keyring [== NULL]
					user->session_keyring = session_keyring;
	atomic_inc(&key->usage); [oops]

At the point thread A dereferences cred->user->session_keyring, thread B
hasn't updated user->session_keyring yet, but thread A assumes it is
populated because install_user_keyrings() returned ok.

The race window is really small but can be exploited if, for example,
thread B is interrupted or preempted after initializing uid_keyring, but
before doing setting session_keyring.

This couldn't be reproduced on a stock kernel.  However, after placing
systemtap probe on 'user->session_keyring = session_keyring;' that
introduced some delay, the kernel could be crashed reliably.

Fix this by checking both pointers before deciding whether to return.
Alternatively, the test could be done away with entirely as it is checked
inside the mutex - but since the mutex is global, that may not be the best
way.

Signed-off-by: David Howells 
Reported-by: Mateusz Guzik 
Signed-off-by: Andrew Morton 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

KEYS: Fix a NULL pointer deref in the user-defined key type

2011-11-21T22:31:18+00:00

commit 9f35a33b8d06263a165efe3541d9aa0cdbd70b3b upstream.

Fix a NULL pointer deref in the user-defined key type whereby updating a
negative key into a fully instantiated key will cause an oops to occur
when the code attempts to free the non-existent old payload.

This results in an oops that looks something like the following:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [] __call_rcu+0x11/0x13e
  PGD 3391d067 PUD 3894a067 PMD 0
  Oops: 0002 [#1] SMP
  CPU 1
  Pid: 4354, comm: keyctl Not tainted 3.1.0-fsdevel+ #1140                  /DG965RY
  RIP: 0010:[]  [] __call_rcu+0x11/0x13e
  RSP: 0018:ffff88003d591df8  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000006e
  RDX: ffffffff8161d0c0 RSI: 0000000000000000 RDI: 0000000000000000
  RBP: ffff88003d591e18 R08: 0000000000000000 R09: ffffffff8152fa6c
  R10: 0000000000000000 R11: 0000000000000300 R12: ffff88003b8f9538
  R13: ffffffff8161d0c0 R14: ffff88003b8f9d50 R15: ffff88003c69f908
  FS:  00007f97eb18c720(0000) GS:ffff88003bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000003d47a000 CR4: 00000000000006e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Process keyctl (pid: 4354, threadinfo ffff88003d590000, task ffff88003c78a040)
  Stack:
   ffff88003e0ffde0 ffff88003b8f9538 0000000000000001 ffff88003b8f9d50
   ffff88003d591e28 ffffffff810860f0 ffff88003d591e68 ffffffff8117bfea
   ffff88003d591e68 ffffffff00000000 ffff88003e0ffde1 ffff88003e0ffde0
  Call Trace:
   [] call_rcu_sched+0x10/0x12
   [] user_update+0x8d/0xa2
   [] key_create_or_update+0x236/0x270
   [] sys_add_key+0x123/0x17e
   [] system_call_fastpath+0x16/0x1b

Signed-off-by: David Howells 
Acked-by: Jeff Layton 
Acked-by: Neil Horman 
Acked-by: Steve Dickson 
Acked-by: James Morris 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

KEYS: Fix error handling in construct_key_and_link()

2011-06-22T01:31:45+00:00

Fix error handling in construct_key_and_link().

If construct_alloc_key() returns an error, it shouldn't pass out through
the normal path as the key_serial() called by the kleave() statement
will oops when it gets an error code in the pointer:

  BUG: unable to handle kernel paging request at ffffffffffffff84
  IP: [] request_key_and_link+0x4d7/0x52f
  ..
  Call Trace:
   [] request_key+0x41/0x75
   [] cifs_get_spnego_key+0x206/0x226 [cifs]
   [] CIFS_SessSetup+0x511/0x1234 [cifs]
   [] cifs_setup_session+0x90/0x1ae [cifs]
   [] cifs_get_smb_ses+0x34b/0x40f [cifs]
   [] cifs_mount+0x13f/0x504 [cifs]
   [] cifs_do_mount+0xc4/0x672 [cifs]
   [] mount_fs+0x69/0x155
   [] vfs_kern_mount+0x63/0xa0
   [] do_kern_mount+0x4d/0xdf
   [] do_mount+0x63c/0x69f
   [] sys_mount+0x88/0xc2
   [] system_call_fastpath+0x16/0x1b

Signed-off-by: David Howells 
Acked-by: Jeff Layton 
Signed-off-by: Linus Torvalds

KEYS/DNS: Fix ____call_usermodehelper() to not lose the session keyring

2011-06-17T16:40:48+00:00

____call_usermodehelper() now erases any credentials set by the
subprocess_inf::init() function.  The problem is that commit
17f60a7da150 ("capabilites: allow the application of capability limits
to usermode helpers") creates and commits new credentials with
prepare_kernel_cred() after the call to the init() function.  This wipes
all keyrings after umh_keys_init() is called.

The best way to deal with this is to put the init() call just prior to
the commit_creds() call, and pass the cred pointer to init().  That
means that umh_keys_init() and suchlike can modify the credentials
_before_ they are published and potentially in use by the rest of the
system.

This prevents request_key() from working as it is prevented from passing
the session keyring it set up with the authorisation token to
/sbin/request-key, and so the latter can't assume the authority to
instantiate the key.  This causes the in-kernel DNS resolver to fail
with ENOKEY unconditionally.

Signed-off-by: David Howells 
Acked-by: Eric Paris 
Tested-by: Jeff Layton 
Signed-off-by: Linus Torvalds

Merge branch 'docs-move' of git://git.kernel.org/pub/scm/linux/kernel/git/rdunlap/linux-docs

2011-05-27T17:25:02+00:00

* 'docs-move' of git://git.kernel.org/pub/scm/linux/kernel/git/rdunlap/linux-docs:
  Create Documentation/security/, move LSM-, credentials-, and keys-related files from Documentation/   to Documentation/security/, add Documentation/security/00-INDEX, and update all occurrences of Documentation/   to Documentation/security/.

Set cred->user_ns in key_replace_session_keyring

2011-05-26T20:49:19+00:00

Since this cred was not created with copy_creds(), it needs to get
initialized.  Otherwise use of syscall(__NR_keyctl, KEYCTL_SESSION_TO_PARENT);
can lead to a NULL deref.  Thanks to Robert for finding this.

But introduced by commit 47a150edc2a ("Cache user_ns in struct cred").

Signed-off-by: Serge E. Hallyn 
Reported-by: Robert Święcki 
Cc: David Howells 
Cc: stable@kernel.org (2.6.39)
Signed-off-by: Linus Torvalds

Merge branch 'next' into for-linus

2011-05-24T12:55:24+00:00

Create Documentation/security/,

2011-05-19T22:59:38+00:00

move LSM-, credentials-, and keys-related files from Documentation/
  to Documentation/security/,
add Documentation/security/00-INDEX, and
update all occurrences of Documentation/
  to Documentation/security/.