<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/security, branch v6.12.20</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.12.20</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.12.20'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2025-03-07T17:25:44Z</updated>
<entry>
<title>ima: Reset IMA_NONACTION_RULE_FLAGS after post_setattr</title>
<updated>2025-03-07T17:25:44Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2025-02-04T12:57:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c479e20dabfd04b35c0f816f4e6db304be5dbc09'/>
<id>urn:sha1:c479e20dabfd04b35c0f816f4e6db304be5dbc09</id>
<content type='text'>
commit 57a0ef02fefafc4b9603e33a18b669ba5ce59ba3 upstream.

Commit 0d73a55208e9 ("ima: re-introduce own integrity cache lock")
mistakenly reverted the performance improvement introduced in commit
42a4c603198f0 ("ima: fix ima_inode_post_setattr"). The unused bit mask was
subsequently removed by commit 11c60f23ed13 ("integrity: Remove unused
macro IMA_ACTION_RULE_FLAGS").

Restore the performance improvement by introducing the new mask
IMA_NONACTION_RULE_FLAGS, equal to IMA_NONACTION_FLAGS without
IMA_NEW_FILE, which is not a rule-specific flag.

Finally, reset IMA_NONACTION_RULE_FLAGS instead of IMA_NONACTION_FLAGS in
process_measurement(), if the IMA_CHANGE_ATTR atomic flag is set (after
file metadata modification).

With this patch, new files for which metadata were modified while they are
still open, can be reopened before the last file close (when security.ima
is written), since the IMA_NEW_FILE flag is not cleared anymore. Otherwise,
appraisal fails because security.ima is missing (files with IMA_NEW_FILE
set are an exception).

Cc: stable@vger.kernel.org # v4.16.x
Fixes: 0d73a55208e9 ("ima: re-introduce own integrity cache lock")
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>landlock: Fix non-TCP sockets restriction</title>
<updated>2025-03-07T17:25:26Z</updated>
<author>
<name>Mikhail Ivanov</name>
<email>ivanov.mikhail1@huawei-partners.com</email>
</author>
<published>2025-02-05T09:36:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=917aa50b75099c883727dc55d154d961a1250639'/>
<id>urn:sha1:917aa50b75099c883727dc55d154d961a1250639</id>
<content type='text'>
[ Upstream commit 854277e2cc8c75dc3c216c82e72523258fcf65b9 ]

Use sk_is_tcp() to check if socket is TCP in bind(2) and connect(2)
hooks.

SMC, MPTCP, SCTP protocols are currently restricted by TCP access
rights.  The purpose of TCP access rights is to provide control over
ports that can be used by userland to establish a TCP connection.
Therefore, it is incorrect to deny bind(2) and connect(2) requests for a
socket of another protocol.

However, SMC, MPTCP and RDS implementations use TCP internal sockets to
establish communication or even to exchange packets over a TCP
connection [1]. Landlock rules that configure bind(2) and connect(2)
usage for TCP sockets should not cover requests for sockets of such
protocols. These protocols have different set of security issues and
security properties, therefore, it is necessary to provide the userland
with the ability to distinguish between them (eg. [2]).

Control over TCP connection used by other protocols can be achieved with
upcoming support of socket creation control [3].

[1] https://lore.kernel.org/all/62336067-18c2-3493-d0ec-6dd6a6d3a1b5@huawei-partners.com/
[2] https://lore.kernel.org/all/20241204.fahVio7eicim@digikod.net/
[3] https://lore.kernel.org/all/20240904104824.1844082-1-ivanov.mikhail1@huawei-partners.com/

Closes: https://github.com/landlock-lsm/linux/issues/40
Fixes: fff69fb03dde ("landlock: Support network rules with TCP bind and connect")
Signed-off-by: Mikhail Ivanov &lt;ivanov.mikhail1@huawei-partners.com&gt;
Link: https://lore.kernel.org/r/20250205093651.1424339-2-ivanov.mikhail1@huawei-partners.com
[mic: Format commit message to 72 columns]
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>KEYS: trusted: dcp: fix improper sg use with CONFIG_VMAP_STACK=y</title>
<updated>2025-02-17T09:05:09Z</updated>
<author>
<name>David Gstir</name>
<email>david@sigma-star.at</email>
</author>
<published>2024-11-13T21:27:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3192f1c54dddb9b5820bf5e8677809949d8e9c66'/>
<id>urn:sha1:3192f1c54dddb9b5820bf5e8677809949d8e9c66</id>
<content type='text'>
commit e8d9fab39d1f87b52932646b2f1e7877aa3fc0f4 upstream.

With vmalloc stack addresses enabled (CONFIG_VMAP_STACK=y) DCP trusted
keys can crash during en- and decryption of the blob encryption key via
the DCP crypto driver. This is caused by improperly using sg_init_one()
with vmalloc'd stack buffers (plain_key_blob).

Fix this by always using kmalloc() for buffers we give to the DCP crypto
driver.

Cc: stable@vger.kernel.org # v6.10+
Fixes: 0e28bf61a5f9 ("KEYS: trusted: dcp: fix leak of blob encryption key")
Signed-off-by: David Gstir &lt;david@sigma-star.at&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tomoyo: don't emit warning in tomoyo_write_control()</title>
<updated>2025-02-17T09:04:50Z</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2024-12-16T10:38:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c9382f380e8d09209b8e5c0def0545852168be25'/>
<id>urn:sha1:c9382f380e8d09209b8e5c0def0545852168be25</id>
<content type='text'>
[ Upstream commit 3df7546fc03b8f004eee0b9e3256369f7d096685 ]

syzbot is reporting too large allocation warning at tomoyo_write_control(),
for one can write a very very long line without new line character. To fix
this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,
for practically a valid line should be always shorter than 32KB where the
"too small to fail" memory-allocation rule applies.

One might try to write a valid line that is longer than 32KB, but such
request will likely fail with -ENOMEM. Therefore, I feel that separately
returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.
There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.

Reported-by: syzbot+7536f77535e5210a5c76@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7536f77535e5210a5c76
Reported-by: Leo Stone &lt;leocstone@gmail.com&gt;
Closes: https://lkml.kernel.org/r/20241216021459.178759-2-leocstone@gmail.com
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>safesetid: check size of policy writes</title>
<updated>2025-02-17T09:04:49Z</updated>
<author>
<name>Leo Stone</name>
<email>leocstone@gmail.com</email>
</author>
<published>2024-12-17T18:26:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=36b385d0f2b4c0bf41d491e19075ecd990d2bf94'/>
<id>urn:sha1:36b385d0f2b4c0bf41d491e19075ecd990d2bf94</id>
<content type='text'>
[ Upstream commit f09ff307c7299392f1c88f763299e24bc99811c7 ]

syzbot attempts to write a buffer with a large size to a sysfs entry
with writes handled by handle_policy_update(), triggering a warning
in kmalloc.

Check the size specified for write buffers before allocating.

Reported-by: syzbot+4eb7a741b3216020043a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=4eb7a741b3216020043a
Signed-off-by: Leo Stone &lt;leocstone@gmail.com&gt;
[PM: subject tweak]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>landlock: Handle weird files</title>
<updated>2025-02-08T08:57:16Z</updated>
<author>
<name>Mickaël Salaün</name>
<email>mic@digikod.net</email>
</author>
<published>2025-01-10T15:39:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2569e65d2eb6ac1afe6cb6dfae476afee8b6771a'/>
<id>urn:sha1:2569e65d2eb6ac1afe6cb6dfae476afee8b6771a</id>
<content type='text'>
[ Upstream commit 49440290a0935f428a1e43a5ac8dc275a647ff80 ]

A corrupted filesystem (e.g. bcachefs) might return weird files.
Instead of throwing a warning and allowing access to such file, treat
them as regular files.

Cc: Dave Chinner &lt;david@fromorbit.com&gt;
Cc: Kent Overstreet &lt;kent.overstreet@linux.dev&gt;
Cc: Paul Moore &lt;paul@paul-moore.com&gt;
Reported-by: syzbot+34b68f850391452207df@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/r/000000000000a65b35061cffca61@google.com
Reported-by: syzbot+360866a59e3c80510a62@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/r/67379b3f.050a0220.85a0.0001.GAE@google.com
Reported-by: Ubisectech Sirius &lt;bugreport@ubisectech.com&gt;
Closes: https://lore.kernel.org/r/c426821d-8380-46c4-a494-7008bbd7dd13.bugreport@ubisectech.com
Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control")
Reviewed-by: Günther Noack &lt;gnoack3000@gmail.com&gt;
Link: https://lore.kernel.org/r/20250110153918.241810-1-mic@digikod.net
Signed-off-by: Mickaël Salaün &lt;mic@digikod.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>apparmor: allocate xmatch for nullpdb inside aa_alloc_null</title>
<updated>2025-01-23T16:23:05Z</updated>
<author>
<name>Ryan Lee</name>
<email>ryan.lee@canonical.com</email>
</author>
<published>2024-08-21T18:01:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4c3f731b253b3454a0fd3d20351c823dd1dea933'/>
<id>urn:sha1:4c3f731b253b3454a0fd3d20351c823dd1dea933</id>
<content type='text'>
commit 17d0d04f3c999e7784648bad70ce1766c3b49d69 upstream.

attach-&gt;xmatch was not set when allocating a null profile, which is used in
complain mode to allocate a learning profile. This was causing downstream
failures in find_attach, which expected a valid xmatch but did not find
one under a certain sequence of profile transitions in complain mode.

This patch ensures the xmatch is set up properly for null profiles.

Signed-off-by: Ryan Lee &lt;ryan.lee@canonical.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
Cc: Paul Kramme &lt;kramme@digitalmanufaktur.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selinux: ignore unknown extended permissions</title>
<updated>2025-01-09T12:33:32Z</updated>
<author>
<name>Thiébaud Weksteen</name>
<email>tweek@google.com</email>
</author>
<published>2024-12-05T01:09:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=efefe36c03a73bb81c0720ce397659a5051b73fa'/>
<id>urn:sha1:efefe36c03a73bb81c0720ce397659a5051b73fa</id>
<content type='text'>
commit 900f83cf376bdaf798b6f5dcb2eae0c822e908b6 upstream.

When evaluating extended permissions, ignore unknown permissions instead
of calling BUG(). This commit ensures that future permissions can be
added without interfering with older kernels.

Cc: stable@vger.kernel.org
Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls")
Signed-off-by: Thiébaud Weksteen &lt;tweek@google.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Acked-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>apparmor: test: Fix memory leak for aa_unpack_strdup()</title>
<updated>2024-12-05T13:02:46Z</updated>
<author>
<name>Jinjie Ruan</name>
<email>ruanjinjie@huawei.com</email>
</author>
<published>2024-10-11T01:22:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d62ee5739a66644b0e7f11e657d562458cdcdea3'/>
<id>urn:sha1:d62ee5739a66644b0e7f11e657d562458cdcdea3</id>
<content type='text'>
commit 7290f59231910ccba427d441a6e8b8c6f6112448 upstream.

The string allocated by kmemdup() in aa_unpack_strdup() is not
freed and cause following memory leaks, free them to fix it.

	unreferenced object 0xffffff80c6af8a50 (size 8):
	  comm "kunit_try_catch", pid 225, jiffies 4294894407
	  hex dump (first 8 bytes):
	    74 65 73 74 69 6e 67 00                          testing.
	  backtrace (crc 5eab668b):
	    [&lt;0000000001e3714d&gt;] kmemleak_alloc+0x34/0x40
	    [&lt;000000006e6c7776&gt;] __kmalloc_node_track_caller_noprof+0x300/0x3e0
	    [&lt;000000006870467c&gt;] kmemdup_noprof+0x34/0x60
	    [&lt;000000001176bb03&gt;] aa_unpack_strdup+0xd0/0x18c
	    [&lt;000000008ecde918&gt;] policy_unpack_test_unpack_strdup_with_null_name+0xf8/0x3ec
	    [&lt;0000000032ef8f77&gt;] kunit_try_run_case+0x13c/0x3ac
	    [&lt;00000000f3edea23&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec
	    [&lt;00000000adf936cf&gt;] kthread+0x2e8/0x374
	    [&lt;0000000041bb1628&gt;] ret_from_fork+0x10/0x20
	unreferenced object 0xffffff80c2a29090 (size 8):
	  comm "kunit_try_catch", pid 227, jiffies 4294894409
	  hex dump (first 8 bytes):
	    74 65 73 74 69 6e 67 00                          testing.
	  backtrace (crc 5eab668b):
	    [&lt;0000000001e3714d&gt;] kmemleak_alloc+0x34/0x40
	    [&lt;000000006e6c7776&gt;] __kmalloc_node_track_caller_noprof+0x300/0x3e0
	    [&lt;000000006870467c&gt;] kmemdup_noprof+0x34/0x60
	    [&lt;000000001176bb03&gt;] aa_unpack_strdup+0xd0/0x18c
	    [&lt;0000000046a45c1a&gt;] policy_unpack_test_unpack_strdup_with_name+0xd0/0x3c4
	    [&lt;0000000032ef8f77&gt;] kunit_try_run_case+0x13c/0x3ac
	    [&lt;00000000f3edea23&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec
	    [&lt;00000000adf936cf&gt;] kthread+0x2e8/0x374
	    [&lt;0000000041bb1628&gt;] ret_from_fork+0x10/0x20

Cc: stable@vger.kernel.org
Fixes: 4d944bcd4e73 ("apparmor: add AppArmor KUnit tests for policy unpack")
Signed-off-by: Jinjie Ruan &lt;ruanjinjie@huawei.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>apparmor: fix 'Do simple duplicate message elimination'</title>
<updated>2024-12-05T13:02:39Z</updated>
<author>
<name>chao liu</name>
<email>liuzgyid@outlook.com</email>
</author>
<published>2023-06-27T02:03:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=97d28eee4028a255531632d52f996fa9f81e58fd'/>
<id>urn:sha1:97d28eee4028a255531632d52f996fa9f81e58fd</id>
<content type='text'>
[ Upstream commit 9b897132424fe76bf6c61f22f9cf12af7f1d1e6a ]

Multiple profiles shared 'ent-&gt;caps', so some logs missed.

Fixes: 0ed3b28ab8bf ("AppArmor: mediation of non file objects")
Signed-off-by: chao liu &lt;liuzgyid@outlook.com&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
