<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/security, branch v4.4.235</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.235</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.235'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-08-21T08:53:02Z</updated>
<entry>
<title>Smack: prevent underflow in smk_set_cipso()</title>
<updated>2020-08-21T08:53:02Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-07-23T15:23:05Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=23e854676593fa65adf1f103aec84e7a03a396e1'/>
<id>urn:sha1:23e854676593fa65adf1f103aec84e7a03a396e1</id>
<content type='text'>
[ Upstream commit 42a2df3e829f3c5562090391b33714b2e2e5ad4a ]

We have an upper bound on "maplevel" but forgot to check for negative
values.

Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Smack: fix another vsscanf out of bounds</title>
<updated>2020-08-21T08:53:02Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-07-23T15:22:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fd9ff27063dd473219a7be89b5d8576c8b70b13d'/>
<id>urn:sha1:fd9ff27063dd473219a7be89b5d8576c8b70b13d</id>
<content type='text'>
[ Upstream commit a6bd4f6d9b07452b0b19842044a6c3ea384b0b88 ]

This is similar to commit 84e99e58e8d1 ("Smack: slab-out-of-bounds in
vsscanf") where we added a bounds check on "rule".

Reported-by: syzbot+a22c6092d003d6fe1122@syzkaller.appspotmail.com
Fixes: f7112e6c9abf ("Smack: allow for significantly longer Smack labels v4")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Smack: fix use-after-free in smk_write_relabel_self()</title>
<updated>2020-08-21T08:52:57Z</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-07-08T20:15:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=415988b1eba2f7dee97612086954b3d0782767e5'/>
<id>urn:sha1:415988b1eba2f7dee97612086954b3d0782767e5</id>
<content type='text'>
commit beb4ee6770a89646659e6a2178538d2b13e2654e upstream.

smk_write_relabel_self() frees memory from the task's credentials with
no locking, which can easily cause a use-after-free because multiple
tasks can share the same credentials structure.

Fix this by using prepare_creds() and commit_creds() to correctly modify
the task's credentials.

Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self":

	#include &lt;fcntl.h&gt;
	#include &lt;pthread.h&gt;
	#include &lt;unistd.h&gt;

	static void *thrproc(void *arg)
	{
		int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY);
		for (;;) write(fd, "foo", 3);
	}

	int main()
	{
		pthread_t t;
		pthread_create(&amp;t, NULL, thrproc, NULL);
		thrproc(NULL);
	}

Reported-by: syzbot+e6416dabb497a650da40@syzkaller.appspotmail.com
Fixes: 38416e53936e ("Smack: limited capability for changing process label")
Cc: &lt;stable@vger.kernel.org&gt; # v4.4+
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nfs: Move call to security_inode_listsecurity into nfs_listxattr</title>
<updated>2020-08-21T08:52:52Z</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2015-12-02T13:44:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=585f3e1690e6783bd9f3561eadf5ef4809a1e734'/>
<id>urn:sha1:585f3e1690e6783bd9f3561eadf5ef4809a1e734</id>
<content type='text'>
[ Upstream commit c4803c497fbdb37e96af614813a7cfb434b6682a ]

Add a nfs_listxattr operation.  Move the call to security_inode_listsecurity
from list operation of the "security.*" xattr handler to nfs_listxattr.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Cc: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Cc: Anna Schumaker &lt;anna.schumaker@netapp.com&gt;
Cc: linux-nfs@vger.kernel.org
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selinux: fix double free</title>
<updated>2020-06-30T00:07:55Z</updated>
<author>
<name>Tom Rix</name>
<email>trix@redhat.com</email>
</author>
<published>2020-06-10T21:57:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=13f03f2bb77717ba7fcab132284b1e9e0fb847fa'/>
<id>urn:sha1:13f03f2bb77717ba7fcab132284b1e9e0fb847fa</id>
<content type='text'>
commit 65de50969a77509452ae590e9449b70a22b923bb upstream.

Clang's static analysis tool reports these double free memory errors.

security/selinux/ss/services.c:2987:4: warning: Attempt to free released memory [unix.Malloc]
                        kfree(bnames[i]);
                        ^~~~~~~~~~~~~~~~
security/selinux/ss/services.c:2990:2: warning: Attempt to free released memory [unix.Malloc]
        kfree(bvalues);
        ^~~~~~~~~~~~~~

So improve the security_get_bools error handling by freeing these variables
and setting their return pointers to NULL and the return len to 0

Cc: stable@vger.kernel.org
Signed-off-by: Tom Rix &lt;trix@redhat.com&gt;
Acked-by: Stephen Smalley &lt;stephen.smalley.work@gmail.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>ima: Directly assign the ima_default_policy pointer to ima_rules</title>
<updated>2020-06-20T08:23:23Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2020-06-03T15:08:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0cd287657a1f9aa33c48dc7d4e521c60de61b68f'/>
<id>urn:sha1:0cd287657a1f9aa33c48dc7d4e521c60de61b68f</id>
<content type='text'>
[ Upstream commit 067a436b1b0aafa593344fddd711a755a58afb3b ]

This patch prevents the following oops:

[   10.771813] BUG: kernel NULL pointer dereference, address: 0000000000000
[...]
[   10.779790] RIP: 0010:ima_match_policy+0xf7/0xb80
[...]
[   10.798576] Call Trace:
[   10.798993]  ? ima_lsm_policy_change+0x2b0/0x2b0
[   10.799753]  ? inode_init_owner+0x1a0/0x1a0
[   10.800484]  ? _raw_spin_lock+0x7a/0xd0
[   10.801592]  ima_must_appraise.part.0+0xb6/0xf0
[   10.802313]  ? ima_fix_xattr.isra.0+0xd0/0xd0
[   10.803167]  ima_must_appraise+0x4f/0x70
[   10.804004]  ima_post_path_mknod+0x2e/0x80
[   10.804800]  do_mknodat+0x396/0x3c0

It occurs when there is a failure during IMA initialization, and
ima_init_policy() is not called. IMA hooks still call ima_match_policy()
but ima_rules is NULL. This patch prevents the crash by directly assigning
the ima_default_policy pointer to ima_rules when ima_rules is defined. This
wouldn't alter the existing behavior, as ima_rules is always set at the end
of ima_init_policy().

Cc: stable@vger.kernel.org # 3.7.x
Fixes: 07f6a79415d7d ("ima: add appraise action keywords and default rules")
Reported-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ima: Fix ima digest hash table key calculation</title>
<updated>2020-06-20T08:23:22Z</updated>
<author>
<name>Krzysztof Struczynski</name>
<email>krzysztof.struczynski@huawei.com</email>
</author>
<published>2020-04-28T07:30:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=856d5ec8daa76cd8ce5eb03a5ad3366d839aa04b'/>
<id>urn:sha1:856d5ec8daa76cd8ce5eb03a5ad3366d839aa04b</id>
<content type='text'>
commit 1129d31b55d509f15e72dc68e4b5c3a4d7b4da8d upstream.

Function hash_long() accepts unsigned long, while currently only one byte
is passed from ima_hash_key(), which calculates a key for ima_htable.

Given that hashing the digest does not give clear benefits compared to
using the digest itself, remove hash_long() and return the modulus
calculated on the first two bytes of the digest with the number of slots.
Also reduce the depth of the hash table by doubling the number of slots.

Cc: stable@vger.kernel.org
Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
Co-developed-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Krzysztof Struczynski &lt;krzysztof.struczynski@huawei.com&gt;
Acked-by: David.Laight@aculab.com (big endian system concerns)
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Smack: slab-out-of-bounds in vsscanf</title>
<updated>2020-06-20T08:23:19Z</updated>
<author>
<name>Casey Schaufler</name>
<email>casey@schaufler-ca.com</email>
</author>
<published>2020-04-09T23:35:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c32e8ef4e3eb902b0018669ee4ff24676eae99b9'/>
<id>urn:sha1:c32e8ef4e3eb902b0018669ee4ff24676eae99b9</id>
<content type='text'>
commit 84e99e58e8d1e26f04c097f4266e431a33987f36 upstream.

Add barrier to soob. Return -EOVERFLOW if the buffer
is exceeded.

Suggested-by: Hillf Danton &lt;hdanton@sina.com&gt;
Reported-by: syzbot+bfdd4a2f07be52351350@syzkaller.appspotmail.com
Signed-off-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>exec: Always set cap_ambient in cap_bprm_set_creds</title>
<updated>2020-06-03T06:12:11Z</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2020-05-25T17:56:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=63d6d52ec88b8b4cab9880036c42bb2a862784f3'/>
<id>urn:sha1:63d6d52ec88b8b4cab9880036c42bb2a862784f3</id>
<content type='text'>
[ Upstream commit a4ae32c71fe90794127b32d26d7ad795813b502e ]

An invariant of cap_bprm_set_creds is that every field in the new cred
structure that cap_bprm_set_creds might set, needs to be set every
time to ensure the fields does not get a stale value.

The field cap_ambient is not set every time cap_bprm_set_creds is
called, which means that if there is a suid or sgid script with an
interpreter that has neither the suid nor the sgid bits set the
interpreter should be able to accept ambient credentials.
Unfortuantely because cap_ambient is not reset to it's original value
the interpreter can not accept ambient credentials.

Given that the ambient capability set is expected to be controlled by
the caller, I don't think this is particularly serious.  But it is
definitely worth fixing so the code works correctly.

I have tested to verify my reading of the code is correct and the
interpreter of a sgid can receive ambient capabilities with this
change and cannot receive ambient capabilities without this change.

Cc: stable@vger.kernel.org
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Fixes: 58319057b784 ("capabilities: ambient capabilities")
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>evm: Check also if *tfm is an error pointer in init_desc()</title>
<updated>2020-05-27T14:40:23Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2020-04-27T10:28:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b30282c3bcc7542fe3faf9f5e1a0980c3c28a507'/>
<id>urn:sha1:b30282c3bcc7542fe3faf9f5e1a0980c3c28a507</id>
<content type='text'>
[ Upstream commit 53de3b080d5eae31d0de219617155dcc34e7d698 ]

This patch avoids a kernel panic due to accessing an error pointer set by
crypto_alloc_shash(). It occurs especially when there are many files that
require an unsupported algorithm, as it would increase the likelihood of
the following race condition:

Task A: *tfm = crypto_alloc_shash() &lt;= error pointer
Task B: if (*tfm == NULL) &lt;= *tfm is not NULL, use it
Task B: rc = crypto_shash_init(desc) &lt;= panic
Task A: *tfm = NULL

This patch uses the IS_ERR_OR_NULL macro to determine whether or not a new
crypto context must be created.

Cc: stable@vger.kernel.org
Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
Co-developed-by: Krzysztof Struczynski &lt;krzysztof.struczynski@huawei.com&gt;
Signed-off-by: Krzysztof Struczynski &lt;krzysztof.struczynski@huawei.com&gt;
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
