<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/security, branch v3.4.22</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/security?h=v3.4.22</id>
<link rel='self' href='https://git.amat.us/linux/atom/security?h=v3.4.22'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-11-26T19:38:02Z</updated>
<entry>
<title>selinux: fix sel_netnode_insert() suspicious rcu dereference</title>
<updated>2012-11-26T19:38:02Z</updated>
<author>
<name>Dave Jones</name>
<email>davej@redhat.com</email>
</author>
<published>2012-11-09T00:09:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=55649211861616c26aa25c9e710c5691837975e4'/>
<id>urn:sha1:55649211861616c26aa25c9e710c5691837975e4</id>
<content type='text'>
commit 88a693b5c1287be4da937699cb82068ce9db0135 upstream.

===============================
[ INFO: suspicious RCU usage. ]
3.5.0-rc1+ #63 Not tainted
-------------------------------
security/selinux/netnode.c:178 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
1 lock held by trinity-child1/8750:
 #0:  (sel_netnode_lock){+.....}, at: [&lt;ffffffff812d8f8a&gt;] sel_netnode_sid+0x16a/0x3e0

stack backtrace:
Pid: 8750, comm: trinity-child1 Not tainted 3.5.0-rc1+ #63
Call Trace:
 [&lt;ffffffff810cec2d&gt;] lockdep_rcu_suspicious+0xfd/0x130
 [&lt;ffffffff812d91d1&gt;] sel_netnode_sid+0x3b1/0x3e0
 [&lt;ffffffff812d8e20&gt;] ? sel_netnode_find+0x1a0/0x1a0
 [&lt;ffffffff812d24a6&gt;] selinux_socket_bind+0xf6/0x2c0
 [&lt;ffffffff810cd1dd&gt;] ? trace_hardirqs_off+0xd/0x10
 [&lt;ffffffff810cdb55&gt;] ? lock_release_holdtime.part.9+0x15/0x1a0
 [&lt;ffffffff81093841&gt;] ? lock_hrtimer_base+0x31/0x60
 [&lt;ffffffff812c9536&gt;] security_socket_bind+0x16/0x20
 [&lt;ffffffff815550ca&gt;] sys_bind+0x7a/0x100
 [&lt;ffffffff816c03d5&gt;] ? sysret_check+0x22/0x5d
 [&lt;ffffffff810d392d&gt;] ? trace_hardirqs_on_caller+0x10d/0x1a0
 [&lt;ffffffff8133b09e&gt;] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [&lt;ffffffff816c03a9&gt;] system_call_fastpath+0x16/0x1b

This patch below does what Paul McKenney suggested in the previous thread.

Signed-off-by: Dave Jones &lt;davej@redhat.com&gt;
Reviewed-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Acked-by: Paul Moore &lt;paul@paul-moore.com&gt;
Cc: Eric Paris &lt;eparis@parisplace.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Yama: handle 32-bit userspace prctl</title>
<updated>2012-10-07T15:32:28Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2012-08-27T18:38:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7d0fcfec4c491eb3c815929be5512ae8d1886553'/>
<id>urn:sha1:7d0fcfec4c491eb3c815929be5512ae8d1886553</id>
<content type='text'>
commit 2e4930eb7c8fb20a39dfb5f8a8f80402710dcea8 upstream.

When running a 64-bit kernel and receiving prctls from a 32-bit
userspace, the "-1" used as an unsigned long will end up being
misdetected. The kernel is looking for 0xffffffffffffffff instead of
0xffffffff. Since prctl lacks a distinct compat interface, Yama needs
to handle this translation itself. As such, support either value as
meaning PR_SET_PTRACER_ANY, to avoid breaking the ABI for 64-bit.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>posix_types.h: Cleanup stale __NFDBITS and related definitions</title>
<updated>2012-08-09T15:31:39Z</updated>
<author>
<name>Josh Boyer</name>
<email>jwboyer@redhat.com</email>
</author>
<published>2012-07-25T14:40:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=27cd8f51344dcf4799c7a092c1797402b833126a'/>
<id>urn:sha1:27cd8f51344dcf4799c7a092c1797402b833126a</id>
<content type='text'>
commit 8ded2bbc1845e19c771eb55209aab166ef011243 upstream.

Recently, glibc made a change to suppress sign-conversion warnings in
FD_SET (glibc commit ceb9e56b3d1).  This uncovered an issue with the
kernel's definition of __NFDBITS if applications #include
&lt;linux/types.h&gt; after including &lt;sys/select.h&gt;.  A build failure would
be seen when passing the -Werror=sign-compare and -D_FORTIFY_SOURCE=2
flags to gcc.

It was suggested that the kernel should either match the glibc
definition of __NFDBITS or remove that entirely.  The current in-kernel
uses of __NFDBITS can be replaced with BITS_PER_LONG, and there are no
uses of the related __FDELT and __FDMASK defines.  Given that, we'll
continue the cleanup that was started with commit 8b3d1cda4f5f
("posix_types: Remove fd_set macros") and drop the remaining unused
macros.

Additionally, linux/time.h has similar macros defined that expand to
nothing so we'll remove those at the same time.

Reported-by: Jeff Law &lt;law@redhat.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Josh Boyer &lt;jwboyer@redhat.com&gt;
[ .. and fix up whitespace as per akpm ]
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SELinux: if sel_make_bools errors don't leave inconsistent state</title>
<updated>2012-06-01T07:18:16Z</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2012-04-04T17:47:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c3083d9d9e5860c365e93b1e96aa65613fa829fb'/>
<id>urn:sha1:c3083d9d9e5860c365e93b1e96aa65613fa829fb</id>
<content type='text'>
commit 154c50ca4eb9ae472f50b6a481213e21ead4457d upstream.

We reset the bool names and values array to NULL, but do not reset the
number of entries in these arrays to 0.  If we error out and then get back
into this function we will walk these NULL pointers based on the belief
that they are non-zero length.

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

</content>
</entry>
<entry>
<title>security: fix compile error in commoncap.c</title>
<updated>2012-04-19T02:56:39Z</updated>
<author>
<name>Jonghwan Choi</name>
<email>jhbird.choi@samsung.com</email>
</author>
<published>2012-04-18T21:23:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=51b79bee627d526199b2f6a6bef8ee0c0739b6d1'/>
<id>urn:sha1:51b79bee627d526199b2f6a6bef8ee0c0739b6d1</id>
<content type='text'>
Add missing "personality.h"
security/commoncap.c: In function 'cap_bprm_set_creds':
security/commoncap.c:510: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function)
security/commoncap.c:510: error: (Each undeclared identifier is reported only once
security/commoncap.c:510: error: for each function it appears in.)

Signed-off-by: Jonghwan Choi &lt;jhbird.choi@samsung.com&gt;
Acked-by: Serge Hallyn &lt;serge.hallyn@canonical.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
</content>
</entry>
<entry>
<title>fcaps: clear the same personality flags as suid when fcaps are used</title>
<updated>2012-04-18T02:37:56Z</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2012-04-17T20:26:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d52fc5dde171f030170a6cb78034d166b13c9445'/>
<id>urn:sha1:d52fc5dde171f030170a6cb78034d166b13c9445</id>
<content type='text'>
If a process increases permissions using fcaps all of the dangerous
personality flags which are cleared for suid apps should also be cleared.
Thus programs given priviledge with fcaps will continue to have address space
randomization enabled even if the parent tried to disable it to make it
easier to attack.

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
Reviewed-by: Serge Hallyn &lt;serge.hallyn@canonical.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
</content>
</entry>
<entry>
<title>Smack: move label list initialization</title>
<updated>2012-04-18T02:02:28Z</updated>
<author>
<name>Casey Schaufler</name>
<email>casey@schaufler-ca.com</email>
</author>
<published>2012-04-18T01:55:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=86812bb0de1a3758dc6c7aa01a763158a7c0638a'/>
<id>urn:sha1:86812bb0de1a3758dc6c7aa01a763158a7c0638a</id>
<content type='text'>
A kernel with Smack enabled will fail if tmpfs has xattr support.

Move the initialization of predefined Smack label
list entries to the LSM initialization from the
smackfs setup. This became an issue when tmpfs
acquired xattr support, but was never correct.

Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
</content>
</entry>
<entry>
<title>Smack: build when CONFIG_AUDIT not defined</title>
<updated>2012-04-10T23:14:40Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2012-04-10T20:26:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=923e9a1399b620d063cd88537c64561bc3d5f905'/>
<id>urn:sha1:923e9a1399b620d063cd88537c64561bc3d5f905</id>
<content type='text'>
This fixes builds where CONFIG_AUDIT is not defined and
CONFIG_SECURITY_SMACK=y.

This got introduced by the stack-usage reducation commit 48c62af68a40
("LSM: shrink the common_audit_data data union").

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Eric Paris &lt;eparis@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>lsm_audit: don't specify the audit pre/post callbacks in 'struct common_audit_data'</title>
<updated>2012-04-03T16:49:59Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-04-02T22:48:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b61c37f57988567c84359645f8202a7c84bc798a'/>
<id>urn:sha1:b61c37f57988567c84359645f8202a7c84bc798a</id>
<content type='text'>
It just bloats the audit data structure for no good reason, since the
only time those fields are filled are just before calling the
common_lsm_audit() function, which is also the only user of those
fields.

So just make them be the arguments to common_lsm_audit(), rather than
bloating that structure that is passed around everywhere, and is
initialized in hot paths.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>SELinux: do not allocate stack space for AVC data unless needed</title>
<updated>2012-04-03T16:49:41Z</updated>
<author>
<name>Eric Paris</name>
<email>eparis@redhat.com</email>
</author>
<published>2012-04-03T16:38:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3f0882c48286e7bdb0bbdec9c4bfa934e0db8e09'/>
<id>urn:sha1:3f0882c48286e7bdb0bbdec9c4bfa934e0db8e09</id>
<content type='text'>
Instead of declaring the entire selinux_audit_data on the stack when we
start an operation on declare it on the stack if we are going to use it.
We know it's usefulness at the end of the security decision and can declare
it there.

Signed-off-by: Eric Paris &lt;eparis@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
