<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/security, branch v5.8.17</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.8.17</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.8.17'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-10-29T09:07:38+00:00</updated>
<entry>
<title>ima: Fix NULL pointer dereference in ima_file_hash</title>
<updated>2020-10-29T09:07:38+00:00</updated>
<author>
<name>KP Singh</name>
<email>kpsingh@google.com</email>
</author>
<published>2020-09-16T18:02:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4a4778394419ad462e36d85ca67560d2a60eccae'/>
<id>urn:sha1:4a4778394419ad462e36d85ca67560d2a60eccae</id>
<content type='text'>
[ Upstream commit aa662fc04f5b290b3979332588bf8d812b189962 ]

ima_file_hash can be called when there is no iint-&gt;ima_hash available
even though the inode exists in the integrity cache. It is fairly
common for a file to not have a hash. (e.g. an mknodat, prior to the
file being closed).

Another example where this can happen (suggested by Jann Horn):

Process A does:

	while(1) {
		unlink("/tmp/imafoo");
		fd = open("/tmp/imafoo", O_RDWR|O_CREAT|O_TRUNC, 0700);
		if (fd == -1) {
			perror("open");
			continue;
		}
		write(fd, "A", 1);
		close(fd);
	}

and Process B does:

	while (1) {
		int fd = open("/tmp/imafoo", O_RDONLY);
		if (fd == -1)
			continue;
    		char *mapping = mmap(NULL, 0x1000, PROT_READ|PROT_EXEC,
			 	     MAP_PRIVATE, fd, 0);
		if (mapping != MAP_FAILED)
			munmap(mapping, 0x1000);
		close(fd);
  	}

Due to the race to get the iint-&gt;mutex between ima_file_hash and
process_measurement iint-&gt;ima_hash could still be NULL.

Fixes: 6beea7afcc72 ("ima: add the ability to query the cached hash of a given file")
Signed-off-by: KP Singh &lt;kpsingh@google.com&gt;
Reviewed-by: Florent Revest &lt;revest@chromium.org&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: Don't ignore errors from crypto_shash_update()</title>
<updated>2020-10-29T09:07:12+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2020-09-04T09:23:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dd5df08801227ad5ca1ba2e0414af68ad2cde9f3'/>
<id>urn:sha1:dd5df08801227ad5ca1ba2e0414af68ad2cde9f3</id>
<content type='text'>
commit 60386b854008adc951c470067f90a2d85b5d520f upstream.

Errors returned by crypto_shash_update() are not checked in
ima_calc_boot_aggregate_tfm() and thus can be overwritten at the next
iteration of the loop. This patch adds a check after calling
crypto_shash_update() and returns immediately if the result is not zero.

Cc: stable@vger.kernel.org
Fixes: 3323eec921efd ("integrity: IMA as an integrity service provider")
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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>device_cgroup: Fix RCU list debugging warning</title>
<updated>2020-10-01T15:36:23+00:00</updated>
<author>
<name>Amol Grover</name>
<email>frextrite@gmail.com</email>
</author>
<published>2020-04-06T10:59:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0b2f403ff302a81feee54e30762601646bc2caea'/>
<id>urn:sha1:0b2f403ff302a81feee54e30762601646bc2caea</id>
<content type='text'>
[ Upstream commit bc62d68e2a0a69fcdcf28aca8edb01abf306b698 ]

exceptions may be traversed using list_for_each_entry_rcu()
outside of an RCU read side critical section BUT under the
protection of decgroup_mutex. Hence add the corresponding
lockdep expression to fix the following false-positive
warning:

[    2.304417] =============================
[    2.304418] WARNING: suspicious RCU usage
[    2.304420] 5.5.4-stable #17 Tainted: G            E
[    2.304422] -----------------------------
[    2.304424] security/device_cgroup.c:355 RCU-list traversed in non-reader section!!

Signed-off-by: Amol Grover &lt;frextrite@gmail.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ima: Fail rule parsing when appraise_flag=blacklist is unsupportable</title>
<updated>2020-08-21T11:15:09+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.microsoft.com</email>
</author>
<published>2020-07-09T06:19:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed276b462fde5578ee96315142b5cf061c2bedbf'/>
<id>urn:sha1:ed276b462fde5578ee96315142b5cf061c2bedbf</id>
<content type='text'>
[ Upstream commit 5f3e92657bbfb63ad3109433d843c89996114b03 ]

Verifying that a file hash is not blacklisted is currently only
supported for files with appended signatures (modsig).  In the future,
this might change.

For now, the "appraise_flag" option is only appropriate for appraise
actions and its "blacklist" value is only appropriate when
CONFIG_IMA_APPRAISE_MODSIG is enabled and "appraise_flag=blacklist" is
only appropriate when "appraise_type=imasig|modsig" is also present.
Make this clear at policy load so that IMA policy authors don't assume
that other uses of "appraise_flag=blacklist" are supported.

Fixes: 273df864cf74 ("ima: Check against blacklisted hashes for files with modsig")
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.microsoft.com&gt;
Reivewed-by: Nayna Jain &lt;nayna@linux.ibm.com&gt;
Tested-by: Nayna Jain &lt;nayna@linux.ibm.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>Smack: prevent underflow in smk_set_cipso()</title>
<updated>2020-08-19T06:26:46+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-07-23T15:23:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1fe77db0d48be086017524f1962d61564e71839a'/>
<id>urn:sha1:1fe77db0d48be086017524f1962d61564e71839a</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-19T06:26:45+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-07-23T15:22:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cdb83ad0c45b4c718ba46e6982f6d1eb5958d54b'/>
<id>urn:sha1:cdb83ad0c45b4c718ba46e6982f6d1eb5958d54b</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>ima: Fail rule parsing when the KEY_CHECK hook is combined with an invalid cond</title>
<updated>2020-08-19T06:26:37+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.microsoft.com</email>
</author>
<published>2020-07-09T06:19:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=263875d7b6065bf789da2a46753d06822873ce2b'/>
<id>urn:sha1:263875d7b6065bf789da2a46753d06822873ce2b</id>
<content type='text'>
[ Upstream commit eb624fe214a2e156ddafd9868377cf91499f789d ]

The KEY_CHECK function only supports the uid, pcr, and keyrings
conditionals. Make this clear at policy load so that IMA policy authors
don't assume that other conditionals are supported.

Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys")
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.microsoft.com&gt;
Reviewed-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.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: Fail rule parsing when the KEXEC_CMDLINE hook is combined with an invalid cond</title>
<updated>2020-08-19T06:26:37+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.microsoft.com</email>
</author>
<published>2020-07-09T06:19:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c7e3b96d12290aad2a8392111d2739806f32845a'/>
<id>urn:sha1:c7e3b96d12290aad2a8392111d2739806f32845a</id>
<content type='text'>
[ Upstream commit db2045f5892a9db7354442bf77f9b03b50ff9ee1 ]

The KEXEC_CMDLINE hook function only supports the pcr conditional. Make
this clear at policy load so that IMA policy authors don't assume that
other conditionals are supported.

Since KEXEC_CMDLINE's inception, ima_match_rules() has always returned
true on any loaded KEXEC_CMDLINE rule without any consideration for
other conditionals present in the rule. Make it clear that pcr is the
only supported KEXEC_CMDLINE conditional by returning an error during
policy load.

An example of why this is a problem can be explained with the following
rule:

 dont_measure func=KEXEC_CMDLINE obj_type=foo_t

An IMA policy author would have assumed that rule is valid because the
parser accepted it but the result was that measurements for all
KEXEC_CMDLINE operations would be disabled.

Fixes: b0935123a183 ("IMA: Define a new hook to measure the kexec boot command line arguments")
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.microsoft.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Reviewed-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.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: Fail rule parsing when buffer hook functions have an invalid action</title>
<updated>2020-08-19T06:26:37+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.microsoft.com</email>
</author>
<published>2020-07-09T06:19:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8e07cdb1778ec000a85a5fbce7697727e4593f32'/>
<id>urn:sha1:8e07cdb1778ec000a85a5fbce7697727e4593f32</id>
<content type='text'>
[ Upstream commit 712183437ebebc89cd086ef96cf9a521fd97fd09 ]

Buffer based hook functions, such as KEXEC_CMDLINE and KEY_CHECK, can
only measure. The process_buffer_measurement() function quietly ignores
all actions except measure so make this behavior clear at the time of
policy load.

The parsing of the keyrings conditional had a check to ensure that it
was only specified with measure actions but the check should be on the
hook function and not the keyrings conditional since
"appraise func=KEY_CHECK" is not a valid rule.

Fixes: b0935123a183 ("IMA: Define a new hook to measure the kexec boot command line arguments")
Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys")
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.microsoft.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: Free the entire rule if it fails to parse</title>
<updated>2020-08-19T06:26:36+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@linux.microsoft.com</email>
</author>
<published>2020-07-09T06:19:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bd6f756234dcb3f880e195f263112d799ab1fc78'/>
<id>urn:sha1:bd6f756234dcb3f880e195f263112d799ab1fc78</id>
<content type='text'>
[ Upstream commit 2bdd737c5687d6dec30e205953146ede8a87dbdd ]

Use ima_free_rule() to fix memory leaks of allocated ima_rule_entry
members, such as .fsname and .keyrings, when an error is encountered
during rule parsing.

Set the args_p pointer to NULL after freeing it in the error path of
ima_lsm_rule_init() so that it isn't freed twice.

This fixes a memory leak seen when loading an rule that contains an
additional piece of allocated memory, such as an fsname, followed by an
invalid conditional:

 # echo "measure fsname=tmpfs bad=cond" &gt; /sys/kernel/security/ima/policy
 -bash: echo: write error: Invalid argument
 # echo scan &gt; /sys/kernel/debug/kmemleak
 # cat /sys/kernel/debug/kmemleak
 unreferenced object 0xffff98e7e4ece6c0 (size 8):
   comm "bash", pid 672, jiffies 4294791843 (age 21.855s)
   hex dump (first 8 bytes):
     74 6d 70 66 73 00 6b a5                          tmpfs.k.
   backtrace:
     [&lt;00000000abab7413&gt;] kstrdup+0x2e/0x60
     [&lt;00000000f11ede32&gt;] ima_parse_add_rule+0x7d4/0x1020
     [&lt;00000000f883dd7a&gt;] ima_write_policy+0xab/0x1d0
     [&lt;00000000b17cf753&gt;] vfs_write+0xde/0x1d0
     [&lt;00000000b8ddfdea&gt;] ksys_write+0x68/0xe0
     [&lt;00000000b8e21e87&gt;] do_syscall_64+0x56/0xa0
     [&lt;0000000089ea7b98&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: f1b08bbcbdaf ("ima: define a new policy condition based on the filesystem name")
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Signed-off-by: Tyler Hicks &lt;tyhicks@linux.microsoft.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>
