<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/security, branch v2.6.27.56</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>selinux: use default proc sid on symlinks</title>
<updated>2010-08-26T23:40:12+00:00</updated>
<author>
<name>Stephen Smalley</name>
<email>sds@tycho.nsa.gov</email>
</author>
<published>2008-09-22T19:41:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5a91177ccf6e429ec66b4f977fc92c105bd909a7'/>
<id>5a91177ccf6e429ec66b4f977fc92c105bd909a7</id>
<content type='text'>
commit ea6b184f7d521a503ecab71feca6e4057562252b upstream.

As we are not concerned with fine-grained control over reading of
symlinks in proc, always use the default proc SID for all proc symlinks.
This should help avoid permission issues upon changes to the proc tree
as in the /proc/net -&gt; /proc/self/net example.
This does not alter labeling of symlinks within /proc/pid directories.
ls -Zd /proc/net output before and after the patch should show the difference.

Signed-off-by:  Stephen D. Smalley &lt;sds@tycho.nsa.gov&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Cc: Florian Mickler &lt;florian@mickler.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

As we are not concerned with fine-grained control over reading of
symlinks in proc, always use the default proc SID for all proc symlinks.
This should help avoid permission issues upon changes to the proc tree
as in the /proc/net -&gt; /proc/self/net example.
This does not alter labeling of symlinks within /proc/pid directories.
ls -Zd /proc/net output before and after the patch should show the difference.

Signed-off-by:  Stephen D. Smalley &lt;sds@tycho.nsa.gov&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Cc: Florian Mickler &lt;florian@mickler.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: find_keyring_by_name() can gain access to a freed keyring</title>
<updated>2010-07-05T18:08:48+00:00</updated>
<author>
<name>Toshiyuki Okajima</name>
<email>toshi.okajima@jp.fujitsu.com</email>
</author>
<published>2010-04-30T13:32:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8e3c5b14d0aa33e347569e53f42f874a83f426c5'/>
<id>8e3c5b14d0aa33e347569e53f42f874a83f426c5</id>
<content type='text'>
commit cea7daa3589d6b550546a8c8963599f7c1a3ae5c upstream.

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-&gt;session_keyring)     keyctl_get_keyring_ID()
|  ||	//=&gt; keyring-&gt;usage = 0        |
|  |schedule_work(&amp;key_cleanup_task)   lookup_user_key()
|  ||                                   |
|  kmem_cache_free(,user)               |
|  .                                    |[KEY_SPEC_USER_KEYRING]
|  .                                    install_user_keyrings()
|  .                                    ||
| key_cleanup() [&lt;= worker_thread()]    ||
|  |                                    ||
|  [spin_lock(&amp;key_serial_lock)]        |[mutex_lock(&amp;key_user_keyr..mutex)]
|  |                                    ||
|  atomic_read() == 0                   ||
|  |{ rb_ease(&amp;key-&gt;serial_node,) }     ||
|  |                                    ||
|  [spin_unlock(&amp;key_serial_lock)]      |find_keyring_by_name()
|  |                                    |||
|  keyring_destroy(keyring)             ||[read_lock(&amp;keyring_name_lock)]
|  ||                                   |||
|  |[write_lock(&amp;keyring_name_lock)]    ||atomic_inc(&amp;keyring-&gt;usage)
|  |.                                   ||| *** GET freeing keyring ***
|  |.                                   ||[read_unlock(&amp;keyring_name_lock)]
|  ||                                   ||
|  |list_del()                          |[mutex_unlock(&amp;key_user_k..mutex)]
|  ||                                   |
|  |[write_unlock(&amp;keyring_name_lock)]  ** INVALID keyring is returned **
|  |                                    .
|  kmem_cache_free(,keyring)            .
|                                       .
|                                       atomic_dec(&amp;keyring-&gt;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: [&lt;ffffffff810e61a3&gt;] 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:[&lt;ffffffff810e61a3&gt;]  [&lt;ffffffff810e61a3&gt;] 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:
	 [&lt;ffffffff810f20ce&gt;] ? get_empty_filp+0x70/0x12f
	 [&lt;ffffffff810face3&gt;] ? do_filp_open+0x145/0x590
	 [&lt;ffffffff810ce208&gt;] ? tlb_finish_mmu+0x2a/0x33
	 [&lt;ffffffff810ce43c&gt;] ? unmap_region+0xd3/0xe2
	 [&lt;ffffffff810e4393&gt;] ? virt_to_head_page+0x9/0x2d
	 [&lt;ffffffff81103916&gt;] ? alloc_fd+0x69/0x10e
	 [&lt;ffffffff810ef4ed&gt;] ? do_sys_open+0x56/0xfc
	 [&lt;ffffffff81008a02&gt;] ? 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 &lt;48&gt; 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
	RIP  [&lt;ffffffff810e61a3&gt;] 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&lt;LOOP; i++))
	do
		/bin/su -c "echo '$i' &gt; /dev/null" $USER
	done
	(( add == 1 )) &amp;&amp; /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&lt;100000; i++))
	do
		keyctl session foo /bin/true || break
	done &gt;&amp;/dev/null

as that uses a keyring named "foo" rather than relying on the user and
user-session named keyrings.

Reported-by: Toshiyuki Okajima &lt;toshi.okajima@jp.fujitsu.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Tested-by: Toshiyuki Okajima &lt;toshi.okajima@jp.fujitsu.com&gt;
Acked-by: Serge Hallyn &lt;serue@us.ibm.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

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-&gt;session_keyring)     keyctl_get_keyring_ID()
|  ||	//=&gt; keyring-&gt;usage = 0        |
|  |schedule_work(&amp;key_cleanup_task)   lookup_user_key()
|  ||                                   |
|  kmem_cache_free(,user)               |
|  .                                    |[KEY_SPEC_USER_KEYRING]
|  .                                    install_user_keyrings()
|  .                                    ||
| key_cleanup() [&lt;= worker_thread()]    ||
|  |                                    ||
|  [spin_lock(&amp;key_serial_lock)]        |[mutex_lock(&amp;key_user_keyr..mutex)]
|  |                                    ||
|  atomic_read() == 0                   ||
|  |{ rb_ease(&amp;key-&gt;serial_node,) }     ||
|  |                                    ||
|  [spin_unlock(&amp;key_serial_lock)]      |find_keyring_by_name()
|  |                                    |||
|  keyring_destroy(keyring)             ||[read_lock(&amp;keyring_name_lock)]
|  ||                                   |||
|  |[write_lock(&amp;keyring_name_lock)]    ||atomic_inc(&amp;keyring-&gt;usage)
|  |.                                   ||| *** GET freeing keyring ***
|  |.                                   ||[read_unlock(&amp;keyring_name_lock)]
|  ||                                   ||
|  |list_del()                          |[mutex_unlock(&amp;key_user_k..mutex)]
|  ||                                   |
|  |[write_unlock(&amp;keyring_name_lock)]  ** INVALID keyring is returned **
|  |                                    .
|  kmem_cache_free(,keyring)            .
|                                       .
|                                       atomic_dec(&amp;keyring-&gt;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: [&lt;ffffffff810e61a3&gt;] 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:[&lt;ffffffff810e61a3&gt;]  [&lt;ffffffff810e61a3&gt;] 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:
	 [&lt;ffffffff810f20ce&gt;] ? get_empty_filp+0x70/0x12f
	 [&lt;ffffffff810face3&gt;] ? do_filp_open+0x145/0x590
	 [&lt;ffffffff810ce208&gt;] ? tlb_finish_mmu+0x2a/0x33
	 [&lt;ffffffff810ce43c&gt;] ? unmap_region+0xd3/0xe2
	 [&lt;ffffffff810e4393&gt;] ? virt_to_head_page+0x9/0x2d
	 [&lt;ffffffff81103916&gt;] ? alloc_fd+0x69/0x10e
	 [&lt;ffffffff810ef4ed&gt;] ? do_sys_open+0x56/0xfc
	 [&lt;ffffffff81008a02&gt;] ? 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 &lt;48&gt; 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
	RIP  [&lt;ffffffff810e61a3&gt;] 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&lt;LOOP; i++))
	do
		/bin/su -c "echo '$i' &gt; /dev/null" $USER
	done
	(( add == 1 )) &amp;&amp; /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&lt;100000; i++))
	do
		keyctl session foo /bin/true || break
	done &gt;&amp;/dev/null

as that uses a keyring named "foo" rather than relying on the user and
user-session named keyrings.

Reported-by: Toshiyuki Okajima &lt;toshi.okajima@jp.fujitsu.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Tested-by: Toshiyuki Okajima &lt;toshi.okajima@jp.fujitsu.com&gt;
Acked-by: Serge Hallyn &lt;serue@us.ibm.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KEYS: Return more accurate error codes</title>
<updated>2010-07-05T18:08:47+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>error27@gmail.com</email>
</author>
<published>2010-05-17T13:42:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e24ad12540142e1ae7e24da1072e977c5b17003b'/>
<id>e24ad12540142e1ae7e24da1072e977c5b17003b</id>
<content type='text'>
commit 4d09ec0f705cf88a12add029c058b53f288cfaa2 upstream.

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 &lt;error27@gmail.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

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 &lt;error27@gmail.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>nfsd: fix vm overcommit crash</title>
<updated>2010-05-26T21:27:09+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@redhat.com</email>
</author>
<published>2008-10-29T21:01:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3f955fe683ffdda7fd68e0b61779001cb9b50011'/>
<id>3f955fe683ffdda7fd68e0b61779001cb9b50011</id>
<content type='text'>
commit 731572d39fcd3498702eda4600db4c43d51e0b26 upstream.

Junjiro R.  Okajima reported a problem where knfsd crashes if you are
using it to export shmemfs objects and run strict overcommit.  In this
situation the current-&gt;mm based modifier to the overcommit goes through a
NULL pointer.

We could simply check for NULL and skip the modifier but we've caught
other real bugs in the past from mm being NULL here - cases where we did
need a valid mm set up (eg the exec bug about a year ago).

To preserve the checks and get the logic we want shuffle the checking
around and add a new helper to the vm_ security wrappers

Also fix a current-&gt;mm reference in nommu that should use the passed mm

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix build]
Reported-by: Junjiro R. Okajima &lt;hooanon05@yahoo.co.jp&gt;
Acked-by: James Morris &lt;jmorris@namei.org&gt;
Signed-off-by: Alan Cox &lt;alan@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

Junjiro R.  Okajima reported a problem where knfsd crashes if you are
using it to export shmemfs objects and run strict overcommit.  In this
situation the current-&gt;mm based modifier to the overcommit goes through a
NULL pointer.

We could simply check for NULL and skip the modifier but we've caught
other real bugs in the past from mm being NULL here - cases where we did
need a valid mm set up (eg the exec bug about a year ago).

To preserve the checks and get the logic we want shuffle the checking
around and add a new helper to the vm_ security wrappers

Also fix a current-&gt;mm reference in nommu that should use the passed mm

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix build]
Reported-by: Junjiro R. Okajima &lt;hooanon05@yahoo.co.jp&gt;
Acked-by: James Morris &lt;jmorris@namei.org&gt;
Signed-off-by: Alan Cox &lt;alan@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>security: use mmap_min_addr indepedently of security models</title>
<updated>2009-07-20T03:44:59+00:00</updated>
<author>
<name>Christoph Lameter</name>
<email>cl@linux-foundation.org</email>
</author>
<published>2009-06-03T20:04:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d6055cd3a734696779d238f9e54174954f22c4c9'/>
<id>d6055cd3a734696779d238f9e54174954f22c4c9</id>
<content type='text'>
commit e0a94c2a63f2644826069044649669b5e7ca75d3 upstream.

This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
It also sets a default mmap_min_addr of 4096.

mmapping of addresses below 4096 will only be possible for processes
with CAP_SYS_RAWIO.

Signed-off-by: Christoph Lameter &lt;cl@linux-foundation.org&gt;
Acked-by: Eric Paris &lt;eparis@redhat.com&gt;
Looks-ok-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
It also sets a default mmap_min_addr of 4096.

mmapping of addresses below 4096 will only be possible for processes
with CAP_SYS_RAWIO.

Signed-off-by: Christoph Lameter &lt;cl@linux-foundation.org&gt;
Acked-by: Eric Paris &lt;eparis@redhat.com&gt;
Looks-ok-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SELinux: BUG in SELinux compat_net code</title>
<updated>2009-06-12T03:01:28+00:00</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2009-06-01T14:21:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=894e24c2c5b6055ef9704b0ffdbacd9d4fdd130b'/>
<id>894e24c2c5b6055ef9704b0ffdbacd9d4fdd130b</id>
<content type='text'>
This patch is not applicable to Linus's tree as the code in question has
been removed for 2.6.30.  I'm sending in case any of the stable
maintainers would like to push to their branches (which I think anything
pre 2.6.30 would like to do).

Ubuntu users were experiencing a kernel panic when they enabled SELinux
due to an old bug in our handling of the compatibility mode network
controls, introduced Jan 1 2008 effad8df44261031a882e1a895415f7186a5098e
Most distros have not used the compat_net code since the new code was
introduced and so noone has hit this problem before.  Ubuntu is the only
distro I know that enabled that legacy cruft by default.  But, I was ask
to look at it and found that the above patch changed a call to
avc_has_perm from if(send_perm) to if(!send_perm) in
selinux_ip_postroute_iptables_compat().  The result is that users who
turn on SELinux and have compat_net set can (and oftern will) BUG() in
avc_has_perm_noaudit since they are requesting 0 permissions.

This patch corrects that accidental bug introduction.

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is not applicable to Linus's tree as the code in question has
been removed for 2.6.30.  I'm sending in case any of the stable
maintainers would like to push to their branches (which I think anything
pre 2.6.30 would like to do).

Ubuntu users were experiencing a kernel panic when they enabled SELinux
due to an old bug in our handling of the compatibility mode network
controls, introduced Jan 1 2008 effad8df44261031a882e1a895415f7186a5098e
Most distros have not used the compat_net code since the new code was
introduced and so noone has hit this problem before.  Ubuntu is the only
distro I know that enabled that legacy cruft by default.  But, I was ask
to look at it and found that the above patch changed a call to
avc_has_perm from if(send_perm) to if(!send_perm) in
selinux_ip_postroute_iptables_compat().  The result is that users who
turn on SELinux and have compat_net set can (and oftern will) BUG() in
avc_has_perm_noaudit since they are requesting 0 permissions.

This patch corrects that accidental bug introduction.

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>unreached code in selinux_ip_postroute_iptables_compat() (CVE-2009-1184)</title>
<updated>2009-05-02T17:25:09+00:00</updated>
<author>
<name>Eugene Teo</name>
<email>eteo@redhat.com</email>
</author>
<published>2009-04-13T02:04:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=910c9e41186762de3717baaf392ab5ff0c454496'/>
<id>910c9e41186762de3717baaf392ab5ff0c454496</id>
<content type='text'>
Not upstream in 2.6.30, as the function was removed there, making this a
non-issue.

Node and port send checks can skip in the compat_net=1 case. This bug
was introduced in commit effad8d.

Signed-off-by: Eugene Teo &lt;eugeneteo@kernel.sg&gt;
Reported-by: Dan Carpenter &lt;error27@gmail.com&gt;
Acked-by: James Morris &lt;jmorris@namei.org&gt;
Acked-by: Paul Moore &lt;paul.moore@hp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Not upstream in 2.6.30, as the function was removed there, making this a
non-issue.

Node and port send checks can skip in the compat_net=1 case. This bug
was introduced in commit effad8d.

Signed-off-by: Eugene Teo &lt;eugeneteo@kernel.sg&gt;
Reported-by: Dan Carpenter &lt;error27@gmail.com&gt;
Acked-by: James Morris &lt;jmorris@namei.org&gt;
Acked-by: Paul Moore &lt;paul.moore@hp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>security/smack: fix oops when setting a size 0 SMACK64 xattr</title>
<updated>2009-05-02T17:23:55+00:00</updated>
<author>
<name>Etienne Basset</name>
<email>etienne.basset@numericable.fr</email>
</author>
<published>2009-03-31T21:54:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2d44563c1619317484982f0e46e246ebc9afe898'/>
<id>2d44563c1619317484982f0e46e246ebc9afe898</id>
<content type='text'>
upstream commit: 4303154e86597885bc3cbc178a48ccbc8213875f

this patch fix an oops in smack when setting a size 0 SMACK64 xattr eg
attr -S -s SMACK64  -V '' somefile
This oops because smk_import_entry treats a 0 length as SMK_MAXLEN

Signed-off-by: Etienne Basset &lt;etienne.basset@numericable.fr&gt;
Reviewed-by: James Morris &lt;jmorris@namei.org&gt;
Acked-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
upstream commit: 4303154e86597885bc3cbc178a48ccbc8213875f

this patch fix an oops in smack when setting a size 0 SMACK64 xattr eg
attr -S -s SMACK64  -V '' somefile
This oops because smk_import_entry treats a 0 length as SMK_MAXLEN

Signed-off-by: Etienne Basset &lt;etienne.basset@numericable.fr&gt;
Reviewed-by: James Morris &lt;jmorris@namei.org&gt;
Acked-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selinux: Fix the NetLabel glue code for setsockopt()</title>
<updated>2009-03-17T00:52:57+00:00</updated>
<author>
<name>Paul Moore</name>
<email>paul.moore@hp.com</email>
</author>
<published>2009-02-20T21:33:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=068c8059e492c269ae6291286e6d942cae652cb6'/>
<id>068c8059e492c269ae6291286e6d942cae652cb6</id>
<content type='text'>
commit 09c50b4a52c01a1f450b8eec819089e228655bfb upstream.

At some point we (okay, I) managed to break the ability for users to use the
setsockopt() syscall to set IPv4 options when NetLabel was not active on the
socket in question.  The problem was noticed by someone trying to use the
"-R" (record route) option of ping:

 # ping -R 10.0.0.1
 ping: record route: No message of desired type

The solution is relatively simple, we catch the unlabeled socket case and
clear the error code, allowing the operation to succeed.  Please note that we
still deny users the ability to override IPv4 options on socket's which have
NetLabel labeling active; this is done to ensure the labeling remains intact.

Signed-off-by: Paul Moore &lt;paul.moore@hp.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

At some point we (okay, I) managed to break the ability for users to use the
setsockopt() syscall to set IPv4 options when NetLabel was not active on the
socket in question.  The problem was noticed by someone trying to use the
"-R" (record route) option of ping:

 # ping -R 10.0.0.1
 ping: record route: No message of desired type

The solution is relatively simple, we catch the unlabeled socket case and
clear the error code, allowing the operation to succeed.  Please note that we
still deny users the ability to override IPv4 options on socket's which have
NetLabel labeling active; this is done to ensure the labeling remains intact.

Signed-off-by: Paul Moore &lt;paul.moore@hp.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>selinux: Fix a panic in selinux_netlbl_inode_permission()</title>
<updated>2009-03-17T00:52:57+00:00</updated>
<author>
<name>Paul Moore</name>
<email>paul.moore@hp.com</email>
</author>
<published>2009-02-27T20:00:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=480f51ace44e212fb825903c57d1535a9b01c1f5'/>
<id>480f51ace44e212fb825903c57d1535a9b01c1f5</id>
<content type='text'>
commit d7f59dc4642ce2fc7b79fcd4ec02ffce7f21eb02 upstream.

Rick McNeal from LSI identified a panic in selinux_netlbl_inode_permission()
caused by a certain sequence of SUNRPC operations.  The problem appears to be
due to the lack of NULL pointer checking in the function; this patch adds the
pointer checks so the function will exit safely in the cases where the socket
is not completely initialized.

Signed-off-by: Paul Moore &lt;paul.moore@hp.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

Rick McNeal from LSI identified a panic in selinux_netlbl_inode_permission()
caused by a certain sequence of SUNRPC operations.  The problem appears to be
due to the lack of NULL pointer checking in the function; this patch adds the
pointer checks so the function will exit safely in the cases where the socket
is not completely initialized.

Signed-off-by: Paul Moore &lt;paul.moore@hp.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
