<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/security/selinux, branch v4.4.214</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.214</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.214'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-08-06T16:28:28+00:00</updated>
<entry>
<title>selinux: fix memory leak in policydb_init()</title>
<updated>2019-08-06T16:28:28+00:00</updated>
<author>
<name>Ondrej Mosnacek</name>
<email>omosnace@redhat.com</email>
</author>
<published>2019-07-25T10:52:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b65cc16ce2a77793aab81b6fc29f6caf4ee3728a'/>
<id>urn:sha1:b65cc16ce2a77793aab81b6fc29f6caf4ee3728a</id>
<content type='text'>
commit 45385237f65aeee73641f1ef737d7273905a233f upstream.

Since roles_init() adds some entries to the role hash table, we need to
destroy also its keys/values on error, otherwise we get a memory leak in
the error path.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: syzbot+fee3a14d4cdf92646287@syzkaller.appspotmail.com
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Ondrej Mosnacek &lt;omosnace@redhat.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selinux: never allow relabeling on context mounts</title>
<updated>2019-05-16T17:45:03+00:00</updated>
<author>
<name>Ondrej Mosnacek</name>
<email>omosnace@redhat.com</email>
</author>
<published>2018-12-21T20:18:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=08794d181ff6843cf22720197668c304c8b781f2'/>
<id>urn:sha1:08794d181ff6843cf22720197668c304c8b781f2</id>
<content type='text'>
commit a83d6ddaebe541570291205cb538e35ad4ff94f9 upstream.

In the SECURITY_FS_USE_MNTPOINT case we never want to allow relabeling
files/directories, so we should never set the SBLABEL_MNT flag. The
'special handling' in selinux_is_sblabel_mnt() is only intended for when
the behavior is set to SECURITY_FS_USE_GENFS.

While there, make the logic in selinux_is_sblabel_mnt() more explicit
and add a BUILD_BUG_ON() to make sure that introducing a new
SECURITY_FS_USE_* forces a review of the logic.

Fixes: d5f3a5f6e7e7 ("selinux: add security in-core xattr support for pstore and debugfs")
Signed-off-by: Ondrej Mosnacek &lt;omosnace@redhat.com&gt;
Reviewed-by: Stephen Smalley &lt;sds@tycho.nsa.gov&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selinux: fix GPF on invalid policy</title>
<updated>2019-01-26T08:42:51+00:00</updated>
<author>
<name>Stephen Smalley</name>
<email>sds@tycho.nsa.gov</email>
</author>
<published>2019-01-09T15:55:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ef38b24344ebb0befdff8d4d427f6581fc24d32'/>
<id>urn:sha1:9ef38b24344ebb0befdff8d4d427f6581fc24d32</id>
<content type='text'>
commit 5b0e7310a2a33c06edc7eb81ffc521af9b2c5610 upstream.

levdatum-&gt;level can be NULL if we encounter an error while loading
the policy during sens_read prior to initializing it.  Make sure
sens_destroy handles that case correctly.

Reported-by: syzbot+6664500f0f18f07a5c0e@syzkaller.appspotmail.com
Signed-off-by: Stephen Smalley &lt;sds@tycho.nsa.gov&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selinux: use GFP_NOWAIT in the AVC kmem_caches</title>
<updated>2018-09-19T20:48:56+00:00</updated>
<author>
<name>Michal Hocko</name>
<email>mhocko@kernel.org</email>
</author>
<published>2017-08-03T08:11:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=97557d161572172d1d6ea317f254e501a4585c41'/>
<id>urn:sha1:97557d161572172d1d6ea317f254e501a4585c41</id>
<content type='text'>
commit 476accbe2f6ef69caeebe99f52a286e12ac35aee upstream.

There is a strange __GFP_NOMEMALLOC usage pattern in SELinux,
specifically GFP_ATOMIC | __GFP_NOMEMALLOC which doesn't make much
sense.  GFP_ATOMIC on its own allows to access memory reserves while
__GFP_NOMEMALLOC dictates we cannot use memory reserves.  Replace this
with the much more sane GFP_NOWAIT in the AVC code as we can tolerate
memory allocation failures in that code.

Signed-off-by: Michal Hocko &lt;mhocko@kernel.org&gt;
Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Amit Pundir &lt;amit.pundir@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selinux: KASAN: slab-out-of-bounds in xattr_getsecurity</title>
<updated>2018-06-06T14:46:21+00:00</updated>
<author>
<name>Sachin Grover</name>
<email>sgrover@codeaurora.org</email>
</author>
<published>2018-05-25T08:31:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ca100fbc48b4e61fb0e6c3a2c81ad4fc4c185bae'/>
<id>urn:sha1:ca100fbc48b4e61fb0e6c3a2c81ad4fc4c185bae</id>
<content type='text'>
commit efe3de79e0b52ca281ef6691480c8c68c82a4657 upstream.

Call trace:
 [&lt;ffffff9203a8d7a8&gt;] dump_backtrace+0x0/0x428
 [&lt;ffffff9203a8dbf8&gt;] show_stack+0x28/0x38
 [&lt;ffffff920409bfb8&gt;] dump_stack+0xd4/0x124
 [&lt;ffffff9203d187e8&gt;] print_address_description+0x68/0x258
 [&lt;ffffff9203d18c00&gt;] kasan_report.part.2+0x228/0x2f0
 [&lt;ffffff9203d1927c&gt;] kasan_report+0x5c/0x70
 [&lt;ffffff9203d1776c&gt;] check_memory_region+0x12c/0x1c0
 [&lt;ffffff9203d17cdc&gt;] memcpy+0x34/0x68
 [&lt;ffffff9203d75348&gt;] xattr_getsecurity+0xe0/0x160
 [&lt;ffffff9203d75490&gt;] vfs_getxattr+0xc8/0x120
 [&lt;ffffff9203d75d68&gt;] getxattr+0x100/0x2c8
 [&lt;ffffff9203d76fb4&gt;] SyS_fgetxattr+0x64/0xa0
 [&lt;ffffff9203a83f70&gt;] el0_svc_naked+0x24/0x28

If user get root access and calls security.selinux setxattr() with an
embedded NUL on a file and then if some process performs a getxattr()
on that file with a length greater than the actual length of the string,
it would result in a panic.

To fix this, add the actual length of the string to the security context
instead of the length passed by the userspace process.

Signed-off-by: Sachin Grover &lt;sgrover@codeaurora.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selinux: do not check open permission on sockets</title>
<updated>2018-04-13T17:50:10+00:00</updated>
<author>
<name>Stephen Smalley</name>
<email>sds@tycho.nsa.gov</email>
</author>
<published>2017-05-12T16:41:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=60c26da547da81cfe9ea1e7d65d514cc89deb82e'/>
<id>urn:sha1:60c26da547da81cfe9ea1e7d65d514cc89deb82e</id>
<content type='text'>
[ Upstream commit ccb544781d34afdb73a9a73ae53035d824d193bf ]

open permission is currently only defined for files in the kernel
(COMMON_FILE_PERMS rather than COMMON_FILE_SOCK_PERMS). Construction of
an artificial test case that tries to open a socket via /proc/pid/fd will
generate a recvfrom avc denial because recvfrom and open happen to map to
the same permission bit in socket vs file classes.

open of a socket via /proc/pid/fd is not supported by the kernel regardless
and will ultimately return ENXIO. But we hit the permission check first and
can thus produce these odd/misleading denials.  Omit the open check when
operating on a socket.

Signed-off-by: Stephen Smalley &lt;sds@tycho.nsa.gov&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selinux: Remove redundant check for unknown labeling behavior</title>
<updated>2018-04-08T09:51:58+00:00</updated>
<author>
<name>Matthias Kaehlcke</name>
<email>mka@chromium.org</email>
</author>
<published>2017-05-19T17:09:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eca9e0aff522167860b8ef1aee4cc416d7b13dbd'/>
<id>urn:sha1:eca9e0aff522167860b8ef1aee4cc416d7b13dbd</id>
<content type='text'>
commit 270e8573145a26de924e2dc644596332d400445b upstream.

The check is already performed in ocontext_read() when the policy is
loaded. Removing the array also fixes the following warning when
building with clang:

security/selinux/hooks.c:338:20: error: variable 'labeling_behaviors'
    is not needed and will not be emitted
    [-Werror,-Wunneeded-internal-declaration]

Signed-off-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Acked-by: Stephen Smalley &lt;sds@tycho.nsa.gov&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
[natechancellor: inode_doinit_with_dentry still present]
Signed-off-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selinux: Remove unnecessary check of array base in selinux_set_mapping()</title>
<updated>2018-04-08T09:51:57+00:00</updated>
<author>
<name>Matthias Kaehlcke</name>
<email>mka@chromium.org</email>
</author>
<published>2017-03-16T22:26:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=76fa23e7de139b47f4eb34c3d7338890ac671a3b'/>
<id>urn:sha1:76fa23e7de139b47f4eb34c3d7338890ac671a3b</id>
<content type='text'>
commit 342e91578eb6909529bc7095964cd44b9c057c4e upstream.

'perms' will never be NULL since it isn't a plain pointer but an array
of u32 values.

This fixes the following warning when building with clang:

security/selinux/ss/services.c:158:16: error: address of array
'p_in-&gt;perms' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
                while (p_in-&gt;perms &amp;&amp; p_in-&gt;perms[k]) {

Signed-off-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Cc: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selinux: check for address length in selinux_socket_bind()</title>
<updated>2018-03-22T08:23:20+00:00</updated>
<author>
<name>Alexander Potapenko</name>
<email>glider@google.com</email>
</author>
<published>2017-03-06T18:46:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=89aadbc66e41aee339979f5b86c8bd6354c6ceac'/>
<id>urn:sha1:89aadbc66e41aee339979f5b86c8bd6354c6ceac</id>
<content type='text'>
[ Upstream commit e2f586bd83177d22072b275edd4b8b872daba924 ]

KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
uninitialized memory in selinux_socket_bind():

==================================================================
BUG: KMSAN: use of unitialized memory
inter: 0
CPU: 3 PID: 1074 Comm: packet2 Tainted: G    B           4.8.0-rc6+ #1916
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 0000000000000000 ffff8800882ffb08 ffffffff825759c8 ffff8800882ffa48
 ffffffff818bf551 ffffffff85bab870 0000000000000092 ffffffff85bab550
 0000000000000000 0000000000000092 00000000bb0009bb 0000000000000002
Call Trace:
 [&lt;     inline     &gt;] __dump_stack lib/dump_stack.c:15
 [&lt;ffffffff825759c8&gt;] dump_stack+0x238/0x290 lib/dump_stack.c:51
 [&lt;ffffffff818bdee6&gt;] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1008
 [&lt;ffffffff818bf0fb&gt;] __msan_warning+0x5b/0xb0 mm/kmsan/kmsan_instr.c:424
 [&lt;ffffffff822dae71&gt;] selinux_socket_bind+0xf41/0x1080 security/selinux/hooks.c:4288
 [&lt;ffffffff8229357c&gt;] security_socket_bind+0x1ec/0x240 security/security.c:1240
 [&lt;ffffffff84265d98&gt;] SYSC_bind+0x358/0x5f0 net/socket.c:1366
 [&lt;ffffffff84265a22&gt;] SyS_bind+0x82/0xa0 net/socket.c:1356
 [&lt;ffffffff81005678&gt;] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
 [&lt;ffffffff8518217c&gt;] entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.o:?
chained origin: 00000000ba6009bb
 [&lt;ffffffff810bb7a7&gt;] save_stack_trace+0x27/0x50 arch/x86/kernel/stacktrace.c:67
 [&lt;     inline     &gt;] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322
 [&lt;     inline     &gt;] kmsan_save_stack mm/kmsan/kmsan.c:337
 [&lt;ffffffff818bd2b8&gt;] kmsan_internal_chain_origin+0x118/0x1e0 mm/kmsan/kmsan.c:530
 [&lt;ffffffff818bf033&gt;] __msan_set_alloca_origin4+0xc3/0x130 mm/kmsan/kmsan_instr.c:380
 [&lt;ffffffff84265b69&gt;] SYSC_bind+0x129/0x5f0 net/socket.c:1356
 [&lt;ffffffff84265a22&gt;] SyS_bind+0x82/0xa0 net/socket.c:1356
 [&lt;ffffffff81005678&gt;] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
 [&lt;ffffffff8518217c&gt;] return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.o:?
origin description: ----address@SYSC_bind (origin=00000000b8c00900)
==================================================================

(the line numbers are relative to 4.8-rc6, but the bug persists upstream)

, when I run the following program as root:

=======================================================
  #include &lt;string.h&gt;
  #include &lt;sys/socket.h&gt;
  #include &lt;netinet/in.h&gt;

  int main(int argc, char *argv[]) {
    struct sockaddr addr;
    int size = 0;
    if (argc &gt; 1) {
      size = atoi(argv[1]);
    }
    memset(&amp;addr, 0, sizeof(addr));
    int fd = socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP);
    bind(fd, &amp;addr, size);
    return 0;
  }
=======================================================

(for different values of |size| other error reports are printed).

This happens because bind() unconditionally copies |size| bytes of
|addr| to the kernel, leaving the rest uninitialized. Then
security_socket_bind() reads the IP address bytes, including the
uninitialized ones, to determine the port, or e.g. pass them further to
sel_netnode_find(), which uses them to calculate a hash.

Signed-off-by: Alexander Potapenko &lt;glider@google.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
[PM: fixed some whitespace damage]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selinux: skip bounded transition processing if the policy isn't loaded</title>
<updated>2018-02-25T10:03:36+00:00</updated>
<author>
<name>Paul Moore</name>
<email>paul@paul-moore.com</email>
</author>
<published>2017-12-05T22:17:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=002924ab7b023d16d3291d5ae600c49cebed1c59'/>
<id>urn:sha1:002924ab7b023d16d3291d5ae600c49cebed1c59</id>
<content type='text'>
commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream.

We can't do anything reasonable in security_bounded_transition() if we
don't have a policy loaded, and in fact we could run into problems
with some of the code inside expecting a policy.  Fix these problems
like we do many others in security/selinux/ss/services.c by checking
to see if the policy is loaded (ss_initialized) and returning quickly
if it isn't.

Reported-by: syzbot &lt;syzkaller-bugs@googlegroups.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Acked-by: Stephen Smalley &lt;sds@tycho.nsa.gov&gt;
Reviewed-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
