KEYS: potential uninitialized variable
authorDan Carpenter <dan.carpenter@oracle.com>
Thu, 16 Jun 2016 14:48:57 +0000 (15:48 +0100)
committermobile promotions <svcmobile_promotions@nvidia.com>
Tue, 15 Nov 2016 20:06:03 +0000 (12:06 -0800)
commitaac729dc148e5d44e5b76a09da1ebbce9359cd61
treeda4d6cdde3a9690ac277e8673602a1e243a6d9db
parent920f0305f3f819f3380ba355013d333a3512705b
KEYS: potential uninitialized variable

If __key_link_begin() failed then "edit" would be uninitialized.  I've
added a check to fix that.

This allows a random user to crash the kernel, though it's quite
difficult to achieve.  There are three ways it can be done as the user
would have to cause an error to occur in __key_link():

 (1) Cause the kernel to run out of memory.  In practice, this is difficult
     to achieve without ENOMEM cropping up elsewhere and aborting the
     attempt.

 (2) Revoke the destination keyring between the keyring ID being looked up
     and it being tested for revocation.  In practice, this is difficult to
     time correctly because the KEYCTL_REJECT function can only be used
     from the request-key upcall process.  Further, users can only make use
     of what's in /sbin/request-key.conf, though this does including a
     rejection debugging test - which means that the destination keyring
     has to be the caller's session keyring in practice.

 (3) Have just enough key quota available to create a key, a new session
     keyring for the upcall and a link in the session keyring, but not then
     sufficient quota to create a link in the nominated destination keyring
     so that it fails with EDQUOT.

The bug can be triggered using option (3) above using something like the
following:

echo 80 >/proc/sys/kernel/keys/root_maxbytes
keyctl request2 user debug:fred negate @t

The above sets the quota to something much lower (80) to make the bug
easier to trigger, but this is dependent on the system.  Note also that
the name of the keyring created contains a random number that may be
between 1 and 10 characters in size, so may throw the test off by
changing the amount of quota used.

Assuming the failure occurs, something like the following will be seen:

kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
------------[ cut here ]------------
kernel BUG at ../mm/slab.c:2821!
...
RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25
RSP: 0018:ffff8804014a7de8  EFLAGS: 00010092
RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
...
Call Trace:
  kfree+0xde/0x1bc
  assoc_array_cancel_edit+0x1f/0x36
  __key_link_end+0x55/0x63
  key_reject_and_link+0x124/0x155
  keyctl_reject_key+0xb6/0xe0
  keyctl_negate_key+0x10/0x12
  SyS_keyctl+0x9f/0xe7
  do_syscall_64+0x63/0x13a
  entry_SYSCALL64_slow_path+0x25/0x25

(cherry picked from commit 38327424b40bcebe2de92d07312c89360ac9229a)
Jira EASS-863

Bug 1797728

Change-Id: Iaf1905f06f52e547654274cbb4827dd03866b71b
Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-on: http://git-master/r/1209532
(cherry picked from commit d84542d36e9d5968c1cef665e9e0a5c70f8eabc4)
Signed-off-by: Mithun Maragiri <mmaragiri@nvidia.com>
Reviewed-on: http://git-master/r/1213221
GVS: Gerrit_Virtual_Submit
Reviewed-by: Vinayak Pane <vpane@nvidia.com>
(cherry picked from commit 552d71467ba0fda2d8816408201b77599e624aca)
Reviewed-on: http://git-master/r/1230814
Reviewed-by: Dhiren Parmar <dparmar@nvidia.com>
Tested-by: Dhiren Parmar <dparmar@nvidia.com>
(cherry picked from commit 842aad2797759fcb19e49457882ab40b7859160f)
Reviewed-on: http://git-master/r/1250872
Reviewed-by: Vaibhav Shinde <vashinde@nvidia.com>
Tested-by: Vaibhav Shinde <vashinde@nvidia.com>
security/keys/key.c