<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/security/keys/key.c, branch linux-3.14.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>KEYS: potential uninitialized variable</title>
<updated>2016-07-27T16:55:49+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2016-06-16T14:48:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ff1dcd2a19f8203324cba737a54707a1ee3f98ea'/>
<id>ff1dcd2a19f8203324cba737a54707a1ee3f98ea</id>
<content type='text'>
commit 38327424b40bcebe2de92d07312c89360ac9229a upstream.

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 &gt;/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:[&lt;ffffffff811600f9&gt;] 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

Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 38327424b40bcebe2de92d07312c89360ac9229a upstream.

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 &gt;/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:[&lt;ffffffff811600f9&gt;] 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

Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Pre-clear struct key on allocation</title>
<updated>2013-12-02T11:24:18+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-12-02T11:24:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2480f57fb3023eb047c5f2d6dfefef41ab9b893c'/>
<id>2480f57fb3023eb047c5f2d6dfefef41ab9b893c</id>
<content type='text'>
The second word of key-&gt;payload does not get initialised in key_alloc(), but
the big_key type is relying on it having been cleared.  The problem comes when
big_key fails to instantiate a large key and doesn't then set the payload.  The
big_key_destroy() op is called from the garbage collector and this assumes that
the dentry pointer stored in the second word will be NULL if instantiation did
not complete.

Therefore just pre-clear the entire struct key on allocation rather than trying
to be clever and only initialising to 0 only those bits that aren't otherwise
initialised.

The lack of initialisation can lead to a bug report like the following if
big_key failed to initialise its file:

	general protection fault: 0000 [#1] SMP
	Modules linked in: ...
	CPU: 0 PID: 51 Comm: kworker/0:1 Not tainted 3.10.0-53.el7.x86_64 #1
	Hardware name: Dell Inc. PowerEdge 1955/0HC513, BIOS 1.4.4 12/09/2008
	Workqueue: events key_garbage_collector
	task: ffff8801294f5680 ti: ffff8801296e2000 task.ti: ffff8801296e2000
	RIP: 0010:[&lt;ffffffff811b4a51&gt;] dput+0x21/0x2d0
	...
	Call Trace:
	 [&lt;ffffffff811a7b06&gt;] path_put+0x16/0x30
	 [&lt;ffffffff81235604&gt;] big_key_destroy+0x44/0x60
	 [&lt;ffffffff8122dc4b&gt;] key_gc_unused_keys.constprop.2+0x5b/0xe0
	 [&lt;ffffffff8122df2f&gt;] key_garbage_collector+0x1df/0x3c0
	 [&lt;ffffffff8107759b&gt;] process_one_work+0x17b/0x460
	 [&lt;ffffffff8107834b&gt;] worker_thread+0x11b/0x400
	 [&lt;ffffffff81078230&gt;] ? rescuer_thread+0x3e0/0x3e0
	 [&lt;ffffffff8107eb00&gt;] kthread+0xc0/0xd0
	 [&lt;ffffffff8107ea40&gt;] ? kthread_create_on_node+0x110/0x110
	 [&lt;ffffffff815c4bec&gt;] ret_from_fork+0x7c/0xb0
	 [&lt;ffffffff8107ea40&gt;] ? kthread_create_on_node+0x110/0x110

Reported-by: Patrik Kis &lt;pkis@redhat.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Stephen Gallagher &lt;sgallagh@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The second word of key-&gt;payload does not get initialised in key_alloc(), but
the big_key type is relying on it having been cleared.  The problem comes when
big_key fails to instantiate a large key and doesn't then set the payload.  The
big_key_destroy() op is called from the garbage collector and this assumes that
the dentry pointer stored in the second word will be NULL if instantiation did
not complete.

Therefore just pre-clear the entire struct key on allocation rather than trying
to be clever and only initialising to 0 only those bits that aren't otherwise
initialised.

The lack of initialisation can lead to a bug report like the following if
big_key failed to initialise its file:

	general protection fault: 0000 [#1] SMP
	Modules linked in: ...
	CPU: 0 PID: 51 Comm: kworker/0:1 Not tainted 3.10.0-53.el7.x86_64 #1
	Hardware name: Dell Inc. PowerEdge 1955/0HC513, BIOS 1.4.4 12/09/2008
	Workqueue: events key_garbage_collector
	task: ffff8801294f5680 ti: ffff8801296e2000 task.ti: ffff8801296e2000
	RIP: 0010:[&lt;ffffffff811b4a51&gt;] dput+0x21/0x2d0
	...
	Call Trace:
	 [&lt;ffffffff811a7b06&gt;] path_put+0x16/0x30
	 [&lt;ffffffff81235604&gt;] big_key_destroy+0x44/0x60
	 [&lt;ffffffff8122dc4b&gt;] key_gc_unused_keys.constprop.2+0x5b/0xe0
	 [&lt;ffffffff8122df2f&gt;] key_garbage_collector+0x1df/0x3c0
	 [&lt;ffffffff8107759b&gt;] process_one_work+0x17b/0x460
	 [&lt;ffffffff8107834b&gt;] worker_thread+0x11b/0x400
	 [&lt;ffffffff81078230&gt;] ? rescuer_thread+0x3e0/0x3e0
	 [&lt;ffffffff8107eb00&gt;] kthread+0xc0/0xd0
	 [&lt;ffffffff8107ea40&gt;] ? kthread_create_on_node+0x110/0x110
	 [&lt;ffffffff815c4bec&gt;] ret_from_fork+0x7c/0xb0
	 [&lt;ffffffff8107ea40&gt;] ? kthread_create_on_node+0x110/0x110

Reported-by: Patrik Kis &lt;pkis@redhat.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Stephen Gallagher &lt;sgallagh@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Fix a race between negating a key and reading the error set</title>
<updated>2013-10-30T11:15:24+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-10-30T11:15:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=74792b0001ee85b845dc82c1a716c6052c2db9de'/>
<id>74792b0001ee85b845dc82c1a716c6052c2db9de</id>
<content type='text'>
key_reject_and_link() marking a key as negative and setting the error with
which it was negated races with keyring searches and other things that read
that error.

The fix is to switch the order in which the assignments are done in
key_reject_and_link() and to use memory barriers.

Kudos to Dave Wysochanski &lt;dwysocha@redhat.com&gt; and Scott Mayhew
&lt;smayhew@redhat.com&gt; for tracking this down.

This may be the cause of:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
IP: [&lt;ffffffff81219011&gt;] wait_for_key_construction+0x31/0x80
PGD c6b2c3067 PUD c59879067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
CPU 0
Modules linked in: ...

Pid: 13359, comm: amqzxma0 Not tainted 2.6.32-358.20.1.el6.x86_64 #1 IBM System x3650 M3 -[7945PSJ]-/00J6159
RIP: 0010:[&lt;ffffffff81219011&gt;] wait_for_key_construction+0x31/0x80
RSP: 0018:ffff880c6ab33758  EFLAGS: 00010246
RAX: ffffffff81219080 RBX: 0000000000000000 RCX: 0000000000000002
RDX: ffffffff81219060 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff880c6ab33768 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff880adfcbce40
R13: ffffffffa03afb84 R14: ffff880adfcbce40 R15: ffff880adfcbce43
FS:  00007f29b8042700(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 0000000c613dc000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process amqzxma0 (pid: 13359, threadinfo ffff880c6ab32000, task ffff880c610deae0)
Stack:
 ffff880adfcbce40 0000000000000000 ffff880c6ab337b8 ffffffff81219695
&lt;d&gt; 0000000000000000 ffff880a000000d0 ffff880c6ab337a8 000000000000000f
&lt;d&gt; ffffffffa03afb93 000000000000000f ffff88186c7882c0 0000000000000014
Call Trace:
 [&lt;ffffffff81219695&gt;] request_key+0x65/0xa0
 [&lt;ffffffffa03a0885&gt;] nfs_idmap_request_key+0xc5/0x170 [nfs]
 [&lt;ffffffffa03a0eb4&gt;] nfs_idmap_lookup_id+0x34/0x80 [nfs]
 [&lt;ffffffffa03a1255&gt;] nfs_map_group_to_gid+0x75/0xa0 [nfs]
 [&lt;ffffffffa039a9ad&gt;] decode_getfattr_attrs+0xbdd/0xfb0 [nfs]
 [&lt;ffffffff81057310&gt;] ? __dequeue_entity+0x30/0x50
 [&lt;ffffffff8100988e&gt;] ? __switch_to+0x26e/0x320
 [&lt;ffffffffa039ae03&gt;] decode_getfattr+0x83/0xe0 [nfs]
 [&lt;ffffffffa039b610&gt;] ? nfs4_xdr_dec_getattr+0x0/0xa0 [nfs]
 [&lt;ffffffffa039b69f&gt;] nfs4_xdr_dec_getattr+0x8f/0xa0 [nfs]
 [&lt;ffffffffa02dada4&gt;] rpcauth_unwrap_resp+0x84/0xb0 [sunrpc]
 [&lt;ffffffffa039b610&gt;] ? nfs4_xdr_dec_getattr+0x0/0xa0 [nfs]
 [&lt;ffffffffa02cf923&gt;] call_decode+0x1b3/0x800 [sunrpc]
 [&lt;ffffffff81096de0&gt;] ? wake_bit_function+0x0/0x50
 [&lt;ffffffffa02cf770&gt;] ? call_decode+0x0/0x800 [sunrpc]
 [&lt;ffffffffa02d99a7&gt;] __rpc_execute+0x77/0x350 [sunrpc]
 [&lt;ffffffff81096c67&gt;] ? bit_waitqueue+0x17/0xd0
 [&lt;ffffffffa02d9ce1&gt;] rpc_execute+0x61/0xa0 [sunrpc]
 [&lt;ffffffffa02d03a5&gt;] rpc_run_task+0x75/0x90 [sunrpc]
 [&lt;ffffffffa02d04c2&gt;] rpc_call_sync+0x42/0x70 [sunrpc]
 [&lt;ffffffffa038ff80&gt;] _nfs4_call_sync+0x30/0x40 [nfs]
 [&lt;ffffffffa038836c&gt;] _nfs4_proc_getattr+0xac/0xc0 [nfs]
 [&lt;ffffffff810aac87&gt;] ? futex_wait+0x227/0x380
 [&lt;ffffffffa038b856&gt;] nfs4_proc_getattr+0x56/0x80 [nfs]
 [&lt;ffffffffa0371403&gt;] __nfs_revalidate_inode+0xe3/0x220 [nfs]
 [&lt;ffffffffa037158e&gt;] nfs_revalidate_mapping+0x4e/0x170 [nfs]
 [&lt;ffffffffa036f147&gt;] nfs_file_read+0x77/0x130 [nfs]
 [&lt;ffffffff811811aa&gt;] do_sync_read+0xfa/0x140
 [&lt;ffffffff81096da0&gt;] ? autoremove_wake_function+0x0/0x40
 [&lt;ffffffff8100bb8e&gt;] ? apic_timer_interrupt+0xe/0x20
 [&lt;ffffffff8100b9ce&gt;] ? common_interrupt+0xe/0x13
 [&lt;ffffffff81228ffb&gt;] ? selinux_file_permission+0xfb/0x150
 [&lt;ffffffff8121bed6&gt;] ? security_file_permission+0x16/0x20
 [&lt;ffffffff81181a95&gt;] vfs_read+0xb5/0x1a0
 [&lt;ffffffff81181bd1&gt;] sys_read+0x51/0x90
 [&lt;ffffffff810dc685&gt;] ? __audit_syscall_exit+0x265/0x290
 [&lt;ffffffff8100b072&gt;] system_call_fastpath+0x16/0x1b

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Dave Wysochanski &lt;dwysocha@redhat.com&gt;
cc: Scott Mayhew &lt;smayhew@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
key_reject_and_link() marking a key as negative and setting the error with
which it was negated races with keyring searches and other things that read
that error.

The fix is to switch the order in which the assignments are done in
key_reject_and_link() and to use memory barriers.

Kudos to Dave Wysochanski &lt;dwysocha@redhat.com&gt; and Scott Mayhew
&lt;smayhew@redhat.com&gt; for tracking this down.

This may be the cause of:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
IP: [&lt;ffffffff81219011&gt;] wait_for_key_construction+0x31/0x80
PGD c6b2c3067 PUD c59879067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
CPU 0
Modules linked in: ...

Pid: 13359, comm: amqzxma0 Not tainted 2.6.32-358.20.1.el6.x86_64 #1 IBM System x3650 M3 -[7945PSJ]-/00J6159
RIP: 0010:[&lt;ffffffff81219011&gt;] wait_for_key_construction+0x31/0x80
RSP: 0018:ffff880c6ab33758  EFLAGS: 00010246
RAX: ffffffff81219080 RBX: 0000000000000000 RCX: 0000000000000002
RDX: ffffffff81219060 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff880c6ab33768 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff880adfcbce40
R13: ffffffffa03afb84 R14: ffff880adfcbce40 R15: ffff880adfcbce43
FS:  00007f29b8042700(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 0000000c613dc000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process amqzxma0 (pid: 13359, threadinfo ffff880c6ab32000, task ffff880c610deae0)
Stack:
 ffff880adfcbce40 0000000000000000 ffff880c6ab337b8 ffffffff81219695
&lt;d&gt; 0000000000000000 ffff880a000000d0 ffff880c6ab337a8 000000000000000f
&lt;d&gt; ffffffffa03afb93 000000000000000f ffff88186c7882c0 0000000000000014
Call Trace:
 [&lt;ffffffff81219695&gt;] request_key+0x65/0xa0
 [&lt;ffffffffa03a0885&gt;] nfs_idmap_request_key+0xc5/0x170 [nfs]
 [&lt;ffffffffa03a0eb4&gt;] nfs_idmap_lookup_id+0x34/0x80 [nfs]
 [&lt;ffffffffa03a1255&gt;] nfs_map_group_to_gid+0x75/0xa0 [nfs]
 [&lt;ffffffffa039a9ad&gt;] decode_getfattr_attrs+0xbdd/0xfb0 [nfs]
 [&lt;ffffffff81057310&gt;] ? __dequeue_entity+0x30/0x50
 [&lt;ffffffff8100988e&gt;] ? __switch_to+0x26e/0x320
 [&lt;ffffffffa039ae03&gt;] decode_getfattr+0x83/0xe0 [nfs]
 [&lt;ffffffffa039b610&gt;] ? nfs4_xdr_dec_getattr+0x0/0xa0 [nfs]
 [&lt;ffffffffa039b69f&gt;] nfs4_xdr_dec_getattr+0x8f/0xa0 [nfs]
 [&lt;ffffffffa02dada4&gt;] rpcauth_unwrap_resp+0x84/0xb0 [sunrpc]
 [&lt;ffffffffa039b610&gt;] ? nfs4_xdr_dec_getattr+0x0/0xa0 [nfs]
 [&lt;ffffffffa02cf923&gt;] call_decode+0x1b3/0x800 [sunrpc]
 [&lt;ffffffff81096de0&gt;] ? wake_bit_function+0x0/0x50
 [&lt;ffffffffa02cf770&gt;] ? call_decode+0x0/0x800 [sunrpc]
 [&lt;ffffffffa02d99a7&gt;] __rpc_execute+0x77/0x350 [sunrpc]
 [&lt;ffffffff81096c67&gt;] ? bit_waitqueue+0x17/0xd0
 [&lt;ffffffffa02d9ce1&gt;] rpc_execute+0x61/0xa0 [sunrpc]
 [&lt;ffffffffa02d03a5&gt;] rpc_run_task+0x75/0x90 [sunrpc]
 [&lt;ffffffffa02d04c2&gt;] rpc_call_sync+0x42/0x70 [sunrpc]
 [&lt;ffffffffa038ff80&gt;] _nfs4_call_sync+0x30/0x40 [nfs]
 [&lt;ffffffffa038836c&gt;] _nfs4_proc_getattr+0xac/0xc0 [nfs]
 [&lt;ffffffff810aac87&gt;] ? futex_wait+0x227/0x380
 [&lt;ffffffffa038b856&gt;] nfs4_proc_getattr+0x56/0x80 [nfs]
 [&lt;ffffffffa0371403&gt;] __nfs_revalidate_inode+0xe3/0x220 [nfs]
 [&lt;ffffffffa037158e&gt;] nfs_revalidate_mapping+0x4e/0x170 [nfs]
 [&lt;ffffffffa036f147&gt;] nfs_file_read+0x77/0x130 [nfs]
 [&lt;ffffffff811811aa&gt;] do_sync_read+0xfa/0x140
 [&lt;ffffffff81096da0&gt;] ? autoremove_wake_function+0x0/0x40
 [&lt;ffffffff8100bb8e&gt;] ? apic_timer_interrupt+0xe/0x20
 [&lt;ffffffff8100b9ce&gt;] ? common_interrupt+0xe/0x13
 [&lt;ffffffff81228ffb&gt;] ? selinux_file_permission+0xfb/0x150
 [&lt;ffffffff8121bed6&gt;] ? security_file_permission+0x16/0x20
 [&lt;ffffffff81181a95&gt;] vfs_read+0xb5/0x1a0
 [&lt;ffffffff81181bd1&gt;] sys_read+0x51/0x90
 [&lt;ffffffff810dc685&gt;] ? __audit_syscall_exit+0x265/0x290
 [&lt;ffffffff8100b072&gt;] system_call_fastpath+0x16/0x1b

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Dave Wysochanski &lt;dwysocha@redhat.com&gt;
cc: Scott Mayhew &lt;smayhew@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Add a 'trusted' flag and a 'trusted only' flag</title>
<updated>2013-09-25T16:17:01+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-08-30T15:07:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=008643b86c5f33c115c84ccdda1725cac3ad50ad'/>
<id>008643b86c5f33c115c84ccdda1725cac3ad50ad</id>
<content type='text'>
Add KEY_FLAG_TRUSTED to indicate that a key either comes from a trusted source
or had a cryptographic signature chain that led back to a trusted key the
kernel already possessed.

Add KEY_FLAGS_TRUSTED_ONLY to indicate that a keyring will only accept links to
keys marked with KEY_FLAGS_TRUSTED.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add KEY_FLAG_TRUSTED to indicate that a key either comes from a trusted source
or had a cryptographic signature chain that led back to a trusted key the
kernel already possessed.

Add KEY_FLAGS_TRUSTED_ONLY to indicate that a keyring will only accept links to
keys marked with KEY_FLAGS_TRUSTED.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Expand the capacity of a keyring</title>
<updated>2013-09-24T09:35:18+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-09-24T09:35:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b2a4df200d570b2c33a57e1ebfa5896e4bc81b69'/>
<id>b2a4df200d570b2c33a57e1ebfa5896e4bc81b69</id>
<content type='text'>
Expand the capacity of a keyring to be able to hold a lot more keys by using
the previously added associative array implementation.  Currently the maximum
capacity is:

	(PAGE_SIZE - sizeof(header)) / sizeof(struct key *)

which, on a 64-bit system, is a little more 500.  However, since this is being
used for the NFS uid mapper, we need more than that.  The new implementation
gives us effectively unlimited capacity.

With some alterations, the keyutils testsuite runs successfully to completion
after this patch is applied.  The alterations are because (a) keyrings that
are simply added to no longer appear ordered and (b) some of the errors have
changed a bit.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Expand the capacity of a keyring to be able to hold a lot more keys by using
the previously added associative array implementation.  Currently the maximum
capacity is:

	(PAGE_SIZE - sizeof(header)) / sizeof(struct key *)

which, on a 64-bit system, is a little more 500.  However, since this is being
used for the NFS uid mapper, we need more than that.  The new implementation
gives us effectively unlimited capacity.

With some alterations, the keyutils testsuite runs successfully to completion
after this patch is applied.  The alterations are because (a) keyrings that
are simply added to no longer appear ordered and (b) some of the errors have
changed a bit.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Drop the permissions argument from __keyring_search_one()</title>
<updated>2013-09-24T09:35:17+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-09-24T09:35:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e57e8669f2ab8350d30f771dd2fdd5377f183db2'/>
<id>e57e8669f2ab8350d30f771dd2fdd5377f183db2</id>
<content type='text'>
Drop the permissions argument from __keyring_search_one() as the only caller
passes 0 here - which causes all checks to be skipped.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Drop the permissions argument from __keyring_search_one() as the only caller
passes 0 here - which causes all checks to be skipped.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Define a __key_get() wrapper to use rather than atomic_inc()</title>
<updated>2013-09-24T09:35:16+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-09-24T09:35:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ccc3e6d9c9aea07a0b60b2b0bfc5b05a704b66d5'/>
<id>ccc3e6d9c9aea07a0b60b2b0bfc5b05a704b66d5</id>
<content type='text'>
Define a __key_get() wrapper to use rather than atomic_inc() on the key usage
count as this makes it easier to hook in refcount error debugging.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Define a __key_get() wrapper to use rather than atomic_inc() on the key usage
count as this makes it easier to hook in refcount error debugging.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Consolidate the concept of an 'index key' for key access</title>
<updated>2013-09-24T09:35:15+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2013-09-24T09:35:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=16feef4340172b7dbb9cba60850e78fa6388adf1'/>
<id>16feef4340172b7dbb9cba60850e78fa6388adf1</id>
<content type='text'>
Consolidate the concept of an 'index key' for accessing keys.  The index key
is the search term needed to find a key directly - basically the key type and
the key description.  We can add to that the description length.

This will be useful when turning a keyring into an associative array rather
than just a pointer block.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Consolidate the concept of an 'index key' for accessing keys.  The index key
is the search term needed to find a key directly - basically the key type and
the key description.  We can add to that the description length.

This will be useful when turning a keyring into an associative array rather
than just a pointer block.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security</title>
<updated>2012-12-16T23:40:50+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-12-16T23:40:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2a74dbb9a86e8102dcd07d284135b4530a84826e'/>
<id>2a74dbb9a86e8102dcd07d284135b4530a84826e</id>
<content type='text'>
Pull security subsystem updates from James Morris:
 "A quiet cycle for the security subsystem with just a few maintenance
  updates."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  Smack: create a sysfs mount point for smackfs
  Smack: use select not depends in Kconfig
  Yama: remove locking from delete path
  Yama: add RCU to drop read locking
  drivers/char/tpm: remove tasklet and cleanup
  KEYS: Use keyring_alloc() to create special keyrings
  KEYS: Reduce initial permissions on keys
  KEYS: Make the session and process keyrings per-thread
  seccomp: Make syscall skipping and nr changes more consistent
  key: Fix resource leak
  keys: Fix unreachable code
  KEYS: Add payload preparsing opportunity prior to key instantiate or update
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull security subsystem updates from James Morris:
 "A quiet cycle for the security subsystem with just a few maintenance
  updates."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  Smack: create a sysfs mount point for smackfs
  Smack: use select not depends in Kconfig
  Yama: remove locking from delete path
  Yama: add RCU to drop read locking
  drivers/char/tpm: remove tasklet and cleanup
  KEYS: Use keyring_alloc() to create special keyrings
  KEYS: Reduce initial permissions on keys
  KEYS: Make the session and process keyrings per-thread
  seccomp: Make syscall skipping and nr changes more consistent
  key: Fix resource leak
  keys: Fix unreachable code
  KEYS: Add payload preparsing opportunity prior to key instantiate or update
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'modules-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux</title>
<updated>2012-10-14T20:39:34+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-10-14T20:39:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d25282d1c9b9bc4cda7f9d3c0205108e99aa7a9d'/>
<id>d25282d1c9b9bc4cda7f9d3c0205108e99aa7a9d</id>
<content type='text'>
Pull module signing support from Rusty Russell:
 "module signing is the highlight, but it's an all-over David Howells frenzy..."

Hmm "Magrathea: Glacier signing key". Somebody has been reading too much HHGTTG.

* 'modules-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (37 commits)
  X.509: Fix indefinite length element skip error handling
  X.509: Convert some printk calls to pr_devel
  asymmetric keys: fix printk format warning
  MODSIGN: Fix 32-bit overflow in X.509 certificate validity date checking
  MODSIGN: Make mrproper should remove generated files.
  MODSIGN: Use utf8 strings in signer's name in autogenerated X.509 certs
  MODSIGN: Use the same digest for the autogen key sig as for the module sig
  MODSIGN: Sign modules during the build process
  MODSIGN: Provide a script for generating a key ID from an X.509 cert
  MODSIGN: Implement module signature checking
  MODSIGN: Provide module signing public keys to the kernel
  MODSIGN: Automatically generate module signing keys if missing
  MODSIGN: Provide Kconfig options
  MODSIGN: Provide gitignore and make clean rules for extra files
  MODSIGN: Add FIPS policy
  module: signature checking hook
  X.509: Add a crypto key parser for binary (DER) X.509 certificates
  MPILIB: Provide a function to read raw data into an MPI
  X.509: Add an ASN.1 decoder
  X.509: Add simple ASN.1 grammar compiler
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull module signing support from Rusty Russell:
 "module signing is the highlight, but it's an all-over David Howells frenzy..."

Hmm "Magrathea: Glacier signing key". Somebody has been reading too much HHGTTG.

* 'modules-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (37 commits)
  X.509: Fix indefinite length element skip error handling
  X.509: Convert some printk calls to pr_devel
  asymmetric keys: fix printk format warning
  MODSIGN: Fix 32-bit overflow in X.509 certificate validity date checking
  MODSIGN: Make mrproper should remove generated files.
  MODSIGN: Use utf8 strings in signer's name in autogenerated X.509 certs
  MODSIGN: Use the same digest for the autogen key sig as for the module sig
  MODSIGN: Sign modules during the build process
  MODSIGN: Provide a script for generating a key ID from an X.509 cert
  MODSIGN: Implement module signature checking
  MODSIGN: Provide module signing public keys to the kernel
  MODSIGN: Automatically generate module signing keys if missing
  MODSIGN: Provide Kconfig options
  MODSIGN: Provide gitignore and make clean rules for extra files
  MODSIGN: Add FIPS policy
  module: signature checking hook
  X.509: Add a crypto key parser for binary (DER) X.509 certificates
  MPILIB: Provide a function to read raw data into an MPI
  X.509: Add an ASN.1 decoder
  X.509: Add simple ASN.1 grammar compiler
  ...
</pre>
</div>
</content>
</entry>
</feed>
