<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/security, branch v5.10.239</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.10.239</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.10.239'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2025-06-27T10:04:20Z</updated>
<entry>
<title>selinux: fix selinux_xfrm_alloc_user() to set correct ctx_len</title>
<updated>2025-06-27T10:04:20Z</updated>
<author>
<name>Stephen Smalley</name>
<email>stephen.smalley.work@gmail.com</email>
</author>
<published>2025-06-13T19:37:05Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e825daf0b2b1da827ed28cd795c9e80dc34f6ede'/>
<id>urn:sha1:e825daf0b2b1da827ed28cd795c9e80dc34f6ede</id>
<content type='text'>
commit 86c8db86af43f52f682e53a0f2f0828683be1e52 upstream.

We should count the terminating NUL byte as part of the ctx_len.
Otherwise, UBSAN logs a warning:
  UBSAN: array-index-out-of-bounds in security/selinux/xfrm.c:99:14
  index 60 is out of range for type 'char [*]'

The allocation itself is correct so there is no actual out of bounds
indexing, just a warning.

Cc: stable@vger.kernel.org
Suggested-by: Christian Göttsche &lt;cgzones@googlemail.com&gt;
Link: https://lore.kernel.org/selinux/CAEjxPJ6tA5+LxsGfOJokzdPeRomBHjKLBVR6zbrg+_w3ZZbM3A@mail.gmail.com/
Signed-off-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>smack: recognize ipv4 CIPSO w/o categories</title>
<updated>2025-06-04T12:37:04Z</updated>
<author>
<name>Konstantin Andreev</name>
<email>andreev@swemel.ru</email>
</author>
<published>2025-01-16T23:40:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d68957733aebac09bbe6a3b609f6e57c1c528c7e'/>
<id>urn:sha1:d68957733aebac09bbe6a3b609f6e57c1c528c7e</id>
<content type='text'>
[ Upstream commit a158a937d864d0034fea14913c1f09c6d5f574b8 ]

If SMACK label has CIPSO representation w/o categories, e.g.:

| # cat /smack/cipso2
| foo  10
| @ 250/2
| ...

then SMACK does not recognize such CIPSO in input ipv4 packets
and substitues '*' label instead. Audit records may look like

| lsm=SMACK fn=smack_socket_sock_rcv_skb action=denied
|   subject="*" object="_" requested=w pid=0 comm="swapper/1" ...

This happens in two steps:

1) security/smack/smackfs.c`smk_set_cipso
   does not clear NETLBL_SECATTR_MLS_CAT
   from (struct smack_known *)skp-&gt;smk_netlabel.flags
   on assigning CIPSO w/o categories:

| rcu_assign_pointer(skp-&gt;smk_netlabel.attr.mls.cat, ncats.attr.mls.cat);
| skp-&gt;smk_netlabel.attr.mls.lvl = ncats.attr.mls.lvl;

2) security/smack/smack_lsm.c`smack_from_secattr
   can not match skp-&gt;smk_netlabel with input packet's
   struct netlbl_lsm_secattr *sap
   because sap-&gt;flags have not NETLBL_SECATTR_MLS_CAT (what is correct)
   but skp-&gt;smk_netlabel.flags have (what is incorrect):

| if ((sap-&gt;flags &amp; NETLBL_SECATTR_MLS_CAT) == 0) {
| 	if ((skp-&gt;smk_netlabel.flags &amp;
| 		 NETLBL_SECATTR_MLS_CAT) == 0)
| 		found = 1;
| 	break;
| }

This commit sets/clears NETLBL_SECATTR_MLS_CAT in
skp-&gt;smk_netlabel.flags according to the presense of CIPSO categories.
The update of smk_netlabel is not atomic, so input packets processing
still may be incorrect during short time while update proceeds.

Signed-off-by: Konstantin Andreev &lt;andreev@swemel.ru&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: Fix use-after-free on a dentry's dname.name</title>
<updated>2025-03-13T11:47:24Z</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2024-03-22T14:03:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=edf287bc610b18d7a9c0c0c1cb2e97b9348c71bb'/>
<id>urn:sha1:edf287bc610b18d7a9c0c0c1cb2e97b9348c71bb</id>
<content type='text'>
commit be84f32bb2c981ca670922e047cdde1488b233de upstream.

-&gt;d_name.name can change on rename and the earlier value can be freed;
there are conditions sufficient to stabilize it (-&gt;d_lock on dentry,
-&gt;d_lock on its parent, -&gt;i_rwsem exclusive on the parent's inode,
rename_lock), but none of those are met at any of the sites. Take a stable
snapshot of the name instead.

Link: https://lore.kernel.org/all/20240202182732.GE2087318@ZenIV/
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
[ Samasth: bp to fix CVE-2024-39494; Minor conflict resolved due to code context change ]
Signed-off-by: Samasth Norway Ananda &lt;samasth.norway.ananda@oracle.com&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-03-13T11:47:01Z</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=f6b37b3e12de638753bce79a2858070b9c4a4ad3'/>
<id>urn:sha1:f6b37b3e12de638753bce79a2858070b9c4a4ad3</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-03-13T11:47:01Z</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=976284b94f2021df09829e37a367e19b84d9e5f3'/>
<id>urn:sha1:976284b94f2021df09829e37a367e19b84d9e5f3</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>selinux: ignore unknown extended permissions</title>
<updated>2025-01-09T12:25:01Z</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=712137b177b45f255ce5687e679d950fcb218256'/>
<id>urn:sha1:712137b177b45f255ce5687e679d950fcb218256</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-14T18:48:09Z</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=f856246ff6da25c4f8fdd73a9c875e878b085e9f'/>
<id>urn:sha1:f856246ff6da25c4f8fdd73a9c875e878b085e9f</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-14T18:48:07Z</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=e47f0e95441be944f2aa077958d2beacc4d6e27d'/>
<id>urn:sha1:e47f0e95441be944f2aa077958d2beacc4d6e27d</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>
<entry>
<title>security/keys: fix slab-out-of-bounds in key_task_permission</title>
<updated>2024-11-17T13:59:35Z</updated>
<author>
<name>Chen Ridong</name>
<email>chenridong@huawei.com</email>
</author>
<published>2024-10-08T12:46:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1e4332581cd4eed75aea77af6f66cdcdda8b49b9'/>
<id>urn:sha1:1e4332581cd4eed75aea77af6f66cdcdda8b49b9</id>
<content type='text'>
[ Upstream commit 4a74da044ec9ec8679e6beccc4306b936b62873f ]

KASAN reports an out of bounds read:
BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36
BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]
BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410
security/keys/permission.c:54
Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362

CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15
Call Trace:
 __dump_stack lib/dump_stack.c:82 [inline]
 dump_stack+0x107/0x167 lib/dump_stack.c:123
 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400
 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560
 kasan_report+0x3a/0x50 mm/kasan/report.c:585
 __kuid_val include/linux/uidgid.h:36 [inline]
 uid_eq include/linux/uidgid.h:63 [inline]
 key_task_permission+0x394/0x410 security/keys/permission.c:54
 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793

This issue was also reported by syzbot.

It can be reproduced by following these steps(more details [1]):
1. Obtain more than 32 inputs that have similar hashes, which ends with the
   pattern '0xxxxxxxe6'.
2. Reboot and add the keys obtained in step 1.

The reproducer demonstrates how this issue happened:
1. In the search_nested_keyrings function, when it iterates through the
   slots in a node(below tag ascend_to_node), if the slot pointer is meta
   and node-&gt;back_pointer != NULL(it means a root), it will proceed to
   descend_to_node. However, there is an exception. If node is the root,
   and one of the slots points to a shortcut, it will be treated as a
   keyring.
2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.
   However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as
   ASSOC_ARRAY_PTR_SUBTYPE_MASK.
3. When 32 keys with the similar hashes are added to the tree, the ROOT
   has keys with hashes that are not similar (e.g. slot 0) and it splits
   NODE A without using a shortcut. When NODE A is filled with keys that
   all hashes are xxe6, the keys are similar, NODE A will split with a
   shortcut. Finally, it forms the tree as shown below, where slot 6 points
   to a shortcut.

                      NODE A
              +------&gt;+---+
      ROOT    |       | 0 | xxe6
      +---+   |       +---+
 xxxx | 0 | shortcut  :   : xxe6
      +---+   |       +---+
 xxe6 :   :   |       |   | xxe6
      +---+   |       +---+
      | 6 |---+       :   : xxe6
      +---+           +---+
 xxe6 :   :           | f | xxe6
      +---+           +---+
 xxe6 | f |
      +---+

4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,
   it may be mistakenly transferred to a key*, leading to a read
   out-of-bounds read.

To fix this issue, one should jump to descend_to_node if the ptr is a
shortcut, regardless of whether the node is root or not.

[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/

[jarkko: tweaked the commit message a bit to have an appropriate closes
 tag.]
Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
Reported-by: syzbot+5b415c07907a2990d1a3@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/
Signed-off-by: Chen Ridong &lt;chenridong@huawei.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selinux: improve error checking in sel_write_load()</title>
<updated>2024-11-08T15:22:00Z</updated>
<author>
<name>Paul Moore</name>
<email>paul@paul-moore.com</email>
</author>
<published>2024-10-25T14:21:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=066314b0b76f61d4d7679f806f19c5c6bcf27441'/>
<id>urn:sha1:066314b0b76f61d4d7679f806f19c5c6bcf27441</id>
<content type='text'>
[ Upstream commit 42c773238037c90b3302bf37a57ae3b5c3f6004a ]

Move our existing input sanity checking to the top of sel_write_load()
and add a check to ensure the buffer size is non-zero.

Move a local variable initialization from the declaration to before it
is used.

Minor style adjustments.

Reported-by: Sam Sun &lt;samsun1006219@gmail.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
[cascardo: keep fsi initialization at its declaration point as it is used earlier]
Signed-off-by: Thadeu Lima de Souza Cascardo &lt;cascardo@igalia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
