<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/security, branch v6.1.12</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.12</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.12'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-02-09T10:28:04+00:00</updated>
<entry>
<title>use less confusing names for iov_iter direction initializers</title>
<updated>2023-02-09T10:28:04+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2022-09-16T00:25:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5a1909510387ddf6c2bf58836dc844f66e8a9efb'/>
<id>urn:sha1:5a1909510387ddf6c2bf58836dc844f66e8a9efb</id>
<content type='text'>
[ Upstream commit de4eda9de2d957ef2d6a8365a01e26a435e958cb ]

READ/WRITE proved to be actively confusing - the meanings are
"data destination, as used with read(2)" and "data source, as
used with write(2)", but people keep interpreting those as
"we read data from it" and "we write data to it", i.e. exactly
the wrong way.

Call them ITER_DEST and ITER_SOURCE - at least that is harder
to misinterpret...

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Stable-dep-of: 6dd88fd59da8 ("vhost-scsi: unbreak any layout for response")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tomoyo: fix broken dependency on *.conf.default</title>
<updated>2023-02-01T07:34:06+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2023-01-07T07:47:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=78cfe7bfe5d1226632968eae7392069089a88a70'/>
<id>urn:sha1:78cfe7bfe5d1226632968eae7392069089a88a70</id>
<content type='text'>
[ Upstream commit eaf2213ba563b2d74a1f2c13a6b258273f689802 ]

If *.conf.default is updated, builtin-policy.h should be rebuilt,
but this does not work when compiled with O= option.

[Without this commit]

  $ touch security/tomoyo/policy/exception_policy.conf.default
  $ make O=/tmp security/tomoyo/
  make[1]: Entering directory '/tmp'
    GEN     Makefile
    CALL    /home/masahiro/ref/linux/scripts/checksyscalls.sh
    DESCEND objtool
  make[1]: Leaving directory '/tmp'

[With this commit]

  $ touch security/tomoyo/policy/exception_policy.conf.default
  $ make O=/tmp security/tomoyo/
  make[1]: Entering directory '/tmp'
    GEN     Makefile
    CALL    /home/masahiro/ref/linux/scripts/checksyscalls.sh
    DESCEND objtool
    POLICY  security/tomoyo/builtin-policy.h
    CC      security/tomoyo/common.o
    AR      security/tomoyo/built-in.a
  make[1]: Leaving directory '/tmp'

$(srctree)/ is essential because $(wildcard ) does not follow VPATH.

Fixes: f02dee2d148b ("tomoyo: Do not generate empty policy files")
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>device_cgroup: Roll back to original exceptions after copy failure</title>
<updated>2023-01-07T10:11:56+00:00</updated>
<author>
<name>Wang Weiyang</name>
<email>wangweiyang2@huawei.com</email>
</author>
<published>2022-10-25T11:31:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=35fe1c238437155153c1aeeb94572b04fa60e0b5'/>
<id>urn:sha1:35fe1c238437155153c1aeeb94572b04fa60e0b5</id>
<content type='text'>
commit e68bfbd3b3c3a0ec3cf8c230996ad8cabe90322f upstream.

When add the 'a *:* rwm' entry to devcgroup A's whitelist, at first A's
exceptions will be cleaned and A's behavior is changed to
DEVCG_DEFAULT_ALLOW. Then parent's exceptions will be copyed to A's
whitelist. If copy failure occurs, just return leaving A to grant
permissions to all devices. And A may grant more permissions than
parent.

Backup A's whitelist and recover original exceptions after copy
failure.

Cc: stable@vger.kernel.org
Fixes: 4cef7299b478 ("device_cgroup: add proper checking when changing default behavior")
Signed-off-by: Wang Weiyang &lt;wangweiyang2@huawei.com&gt;
Reviewed-by: Aristeu Rozanski &lt;aris@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>ima: Fix memory leak in __ima_inode_hash()</title>
<updated>2023-01-07T10:11:52+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2022-11-02T16:30:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f375bcf69f58fd0744c9dfd1b6b891a27301d67b'/>
<id>urn:sha1:f375bcf69f58fd0744c9dfd1b6b891a27301d67b</id>
<content type='text'>
commit 8c1d6a050a0f16e0a9d32eaf53b965c77279c6f8 upstream.

Commit f3cc6b25dcc5 ("ima: always measure and audit files in policy") lets
measurement or audit happen even if the file digest cannot be calculated.

As a result, iint-&gt;ima_hash could have been allocated despite
ima_collect_measurement() returning an error.

Since ima_hash belongs to a temporary inode metadata structure, declared
at the beginning of __ima_inode_hash(), just add a kfree() call if
ima_collect_measurement() returns an error different from -ENOMEM (in that
case, ima_hash should not have been allocated).

Cc: stable@vger.kernel.org
Fixes: 280fe8367b0d ("ima: Always return a file measurement in ima_file_hash()")
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>ima: Fix a potential NULL pointer access in ima_restore_measurement_list</title>
<updated>2023-01-07T10:11:52+00:00</updated>
<author>
<name>Huaxin Lu</name>
<email>luhuaxin1@huawei.com</email>
</author>
<published>2022-11-02T16:09:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3ac71fd8ffa11b78f54200f3fd988f887c658ded'/>
<id>urn:sha1:3ac71fd8ffa11b78f54200f3fd988f887c658ded</id>
<content type='text'>
commit 11220db412edae8dba58853238f53258268bdb88 upstream.

In restore_template_fmt, when kstrdup fails, a non-NULL value will still be
returned, which causes a NULL pointer access in template_desc_init_fields.

Fixes: c7d09367702e ("ima: support restoring multiple template formats")
Cc: stable@kernel.org
Co-developed-by: Jiaming Li &lt;lijiaming30@huawei.com&gt;
Signed-off-by: Jiaming Li &lt;lijiaming30@huawei.com&gt;
Signed-off-by: Huaxin Lu &lt;luhuaxin1@huawei.com&gt;
Reviewed-by: Stefan Berger &lt;stefanb@linux.ibm.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>efi: Add iMac Pro 2017 to uefi skip cert quirk</title>
<updated>2023-01-07T10:11:51+00:00</updated>
<author>
<name>Aditya Garg</name>
<email>gargaditya08@live.com</email>
</author>
<published>2022-10-27T10:01:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=19d5b47b0e09e61d0bc213d85c75f1e03172e72a'/>
<id>urn:sha1:19d5b47b0e09e61d0bc213d85c75f1e03172e72a</id>
<content type='text'>
commit 0be56a116220f9e5731a6609e66a11accfe8d8e2 upstream.

The iMac Pro 2017 is also a T2 Mac. Thus add it to the list of uefi skip
cert.

Cc: stable@vger.kernel.org
Fixes: 155ca952c7ca ("efi: Do not import certificates from UEFI Secure Boot for T2 Macs")
Link: https://lore.kernel.org/linux-integrity/9D46D92F-1381-4F10-989C-1A12CD2FFDD8@live.com/
Signed-off-by: Aditya Garg &lt;gargaditya08@live.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>ima: Fix hash dependency to correct algorithm</title>
<updated>2023-01-07T10:11:46+00:00</updated>
<author>
<name>Tianjia Zhang</name>
<email>tianjia.zhang@linux.alibaba.com</email>
</author>
<published>2022-11-25T12:18:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2d627fbb50267e89ad4070acdfef1c7845c33280'/>
<id>urn:sha1:2d627fbb50267e89ad4070acdfef1c7845c33280</id>
<content type='text'>
commit b6018af440a07bd0d74b58c4e18045f4a8dbfe6b upstream.

Commit d2825fa9365d ("crypto: sm3,sm4 - move into crypto directory") moves
the SM3 and SM4 stand-alone library and the algorithm implementation for
the Crypto API into the same directory, and the corresponding relationship
of Kconfig is modified, CONFIG_CRYPTO_SM3/4 corresponds to the stand-alone
library of SM3/4, and CONFIG_CRYPTO_SM3/4_GENERIC corresponds to the
algorithm implementation for the Crypto API. Therefore, it is necessary
for this module to depend on the correct algorithm.

Fixes: d2825fa9365d ("crypto: sm3,sm4 - move into crypto directory")
Cc: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Cc: stable@vger.kernel.org # v5.19+
Signed-off-by: Tianjia Zhang &lt;tianjia.zhang@linux.alibaba.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>security: Restrict CONFIG_ZERO_CALL_USED_REGS to gcc or clang &gt; 15.0.6</title>
<updated>2022-12-31T12:33:10+00:00</updated>
<author>
<name>Nathan Chancellor</name>
<email>nathan@kernel.org</email>
</author>
<published>2022-12-14T23:26:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=21ca0bfa11bbb9a9207f5d2104f47d3d71b4616e'/>
<id>urn:sha1:21ca0bfa11bbb9a9207f5d2104f47d3d71b4616e</id>
<content type='text'>
commit d6a9fb87e9d18f3394a9845546bbe868efdccfd2 upstream.

A bad bug in clang's implementation of -fzero-call-used-regs can result
in NULL pointer dereferences (see the links above the check for more
information). Restrict CONFIG_CC_HAS_ZERO_CALL_USED_REGS to either a
supported GCC version or a clang newer than 15.0.6, which will catch
both a theoretical 15.0.7 and the upcoming 16.0.0, which will both have
the bug fixed.

Cc: stable@vger.kernel.org # v5.15+
Signed-off-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Link: https://lore.kernel.org/r/20221214232602.4118147-1-nathan@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ima: Simplify ima_lsm_copy_rule</title>
<updated>2022-12-31T12:33:08+00:00</updated>
<author>
<name>GUO Zihua</name>
<email>guozihua@huawei.com</email>
</author>
<published>2022-09-21T12:58:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=26e69e719a2f977c3676bd0556a2eac6b4f1c7d8'/>
<id>urn:sha1:26e69e719a2f977c3676bd0556a2eac6b4f1c7d8</id>
<content type='text'>
[ Upstream commit d57378d3aa4d864d9e590482602068af1b20c0c5 ]

Currently ima_lsm_copy_rule() set the arg_p field of the source rule to
NULL, so that the source rule could be freed afterward. It does not make
sense for this behavior to be inside a "copy" function. So move it
outside and let the caller handle this field.

ima_lsm_copy_rule() now produce a shallow copy of the original entry
including args_p field. Meaning only the lsm.rule and the rule itself
should be freed for the original rule. Thus, instead of calling
ima_lsm_free_rule() which frees lsm.rule as well as args_p field, free
the lsm.rule directly.

Signed-off-by: GUO Zihua &lt;guozihua@huawei.com&gt;
Reviewed-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>LoadPin: Ignore the "contents" argument of the LSM hooks</title>
<updated>2022-12-31T12:33:07+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2022-12-09T19:54:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c5e64f0a8d356616329ea26382b86dd191f9d70'/>
<id>urn:sha1:2c5e64f0a8d356616329ea26382b86dd191f9d70</id>
<content type='text'>
[ Upstream commit 1a17e5b513ceebf21100027745b8731b4728edf7 ]

LoadPin only enforces the read-only origin of kernel file reads. Whether
or not it was a partial read isn't important. Remove the overly
conservative checks so that things like partial firmware reads will
succeed (i.e. reading a firmware header).

Fixes: 2039bda1fa8d ("LSM: Add "contents" flag to kernel_read_file hook")
Cc: Paul Moore &lt;paul@paul-moore.com&gt;
Cc: James Morris &lt;jmorris@namei.org&gt;
Cc: "Serge E. Hallyn" &lt;serge@hallyn.com&gt;
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Serge Hallyn &lt;serge@hallyn.com&gt;
Tested-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://lore.kernel.org/r/20221209195453.never.494-kees@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
