* Re: [syzbot] [lsm?] WARNING in put_cred_rcu
From: Christian Brauner @ 2025-11-10 8:45 UTC (permalink / raw)
To: syzbot
Cc: linux-kernel, linux-security-module, luto, peterz, syzkaller-bugs,
tglx
In-Reply-To: <690dfca7.a70a0220.22f260.004d.GAE@google.com>
On Fri, Nov 07, 2025 at 06:05:27AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 17490bd0527f Add linux-next specific files for 20251104
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16c09bcd980000
> kernel config: https://syzkaller.appspot.com/x/.config?x=9995c0d2611ab121
> dashboard link: https://syzkaller.appspot.com/bug?extid=553c4078ab14e3cf3358
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1500a532580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e0a114580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/a4d318147846/disk-17490bd0.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/86641a470170/vmlinux-17490bd0.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/35c008a540c8/bzImage-17490bd0.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+553c4078ab14e3cf3358@syzkaller.appspotmail.com
#syz test: https://github.com/brauner/linux.git work.namespace-6.19.fixes
^ permalink raw reply
* Re: [RFC PATCH 0/3] mt-exec: fix deadlock with ptrace_attach()
From: Bernd Edlinger @ 2025-11-10 5:28 UTC (permalink / raw)
To: Oleg Nesterov, Linus Torvalds, Dmitry Levin
Cc: Alexander Viro, Alexey Dobriyan, Kees Cook, Andy Lutomirski,
Will Drewry, Christian Brauner, Andrew Morton, Michal Hocko,
Serge Hallyn, James Morris, Randy Dunlap, Suren Baghdasaryan,
Yafang Shao, Helge Deller, Eric W. Biederman, Adrian Reber,
Thomas Gleixner, Jens Axboe, Alexei Starovoitov,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest, linux-mm, linux-security-module, tiozhang,
Luis Chamberlain, Paulo Alcantara (SUSE), Sergey Senozhatsky,
Frederic Weisbecker, YueHaibing, Paul Moore, Aleksa Sarai,
Stefan Roesch, Chao Yu, xu xin, Jeff Layton, Jan Kara,
David Hildenbrand, Dave Chinner, Shuah Khan, Elena Reshetova,
David Windsor, Mateusz Guzik, Ard Biesheuvel,
Joel Fernandes (Google), Matthew Wilcox (Oracle),
Hans Liljestrand, Penglei Jiang, Lorenzo Stoakes, Adrian Ratiu,
Ingo Molnar, Peter Zijlstra (Intel), Cyrill Gorcunov,
Eric Dumazet
In-Reply-To: <aRDL3HOB21pMVMWC@redhat.com>
Hi Oleg,
I have not been able to update my patch with your and Peter Peter Zijlstra's
kind suggestions, because I am currently too busy with my role as openssl maintainer.
Just for clarification, my patch is 10% about deadlocks, and 90% about security.
The idea is that if the de_thread is blocked, and the debugger may be trying to
ptrace the exec thread. That must succeed or fail. So the debugger can release
the zombie threads.
The security issue is when the debugged process tries to exec a SUID process
like /usr/bin/passwd
In that case the new credentials are determined differently when the PTRACE is
already attached (i.e. non-root), than when it is not yet attached (root user).
My attempt at fixing this, determines the new credentials and the new dumpability
as root user when the debugger did not yet attach before the de_thread.
And keeps this decision.
When the debugger wants to attach the de_thread the debug-user access rights are
checked against the current user and additionally against the new user credentials.
This I did by quickly switching the user credenitals to the next user and back again,
under the cred_guard_mutex, which should make that safe.
So at this time I have only one request for you.
Could you please try out how the test case in my patch behaves with your fix?
Thanks
Bernd.
On 11/9/25 18:14, Oleg Nesterov wrote:
> Not for inclusion yet. 2/2 is untested, incomplete, possibly buggy.
>
> But could you review at least the intent? Do you see any problem with
> this approach?
>
> This problem is very, very old. It seems that nobody can suggest a
> simple/clean fix...
>
> Oleg.
> ---
>
> fs/binfmt_elf.c | 4 +-
> fs/binfmt_elf_fdpic.c | 4 +-
> fs/binfmt_flat.c | 4 +-
> fs/exec.c | 142 +++++++++++++++++++++++-------------------------
> include/linux/binfmts.h | 2 +-
> kernel/exit.c | 9 +--
> kernel/signal.c | 6 +-
> 7 files changed, 87 insertions(+), 84 deletions(-)
>
^ permalink raw reply
* [PATCH] security: Add KUnit tests for rootid_owns_currentns()
From: ryan foster @ 2025-11-10 1:16 UTC (permalink / raw)
To: linux-security-module; +Cc: linux-kernel, kunit-dev, serge, paul
[-- Attachment #1.1: Type: text/plain, Size: 111 bytes --]
Please review this patch that adds KUnit tests for
rootid_owns_currentns() function in security/commoncap.c
[-- Attachment #1.2: Type: text/html, Size: 138 bytes --]
[-- Attachment #2: 0001-security-Add-KUnit-tests-for-rootid_owns_currentns.patch --]
[-- Type: text/x-patch, Size: 6553 bytes --]
From 12ab4ef96bdc856cb7287b442ab0b545c6c8a4cb Mon Sep 17 00:00:00 2001
From: Ryan Foster <foster.ryan.r@gmail.com>
Date: Sun, 9 Nov 2025 16:51:26 -0800
Subject: [PATCH] security: Add KUnit tests for rootid_owns_currentns()
The rootid_owns_currentns() function in security/commoncap.c is a
security-critical function used to determine if a root ID from a
parent namespace owns the current namespace. This function is used
in multiple security-critical paths:
1. cap_inode_getsecurity() - file capability retrieval
2. get_vfs_caps_from_disk() - file capability loading during exec
Despite its security-critical nature, this function had no test
coverage. This patch adds KUnit tests to verify the function's
behavior in various scenarios:
- Root ID in init namespace (positive case)
- Invalid vfsuid (negative case)
- Non-root UID (negative case)
The function is made testable by exporting it when
CONFIG_SECURITY_COMMONCAP_KUNIT_TEST is enabled, while maintaining
static visibility in production builds.
This follows the pattern established by other security subsystems
(IPE, Landlock) for KUnit testing.
Signed-off-by: Ryan Foster <foster.ryan.r@gmail.com>
---
security/Kconfig | 17 ++++++
security/Makefile | 1 +
security/commoncap.c | 5 ++
security/commoncap_test.c | 109 ++++++++++++++++++++++++++++++++++++++
4 files changed, 132 insertions(+)
create mode 100644 security/commoncap_test.c
diff --git a/security/Kconfig b/security/Kconfig
index 285f284dfcac..c7b3f42ef875 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -284,6 +284,23 @@ config LSM
If unsure, leave this as the default.
+config SECURITY_COMMONCAP_KUNIT_TEST
+ bool "Build KUnit tests for commoncap" if !KUNIT_ALL_TESTS
+ depends on KUNIT=y
+ default KUNIT_ALL_TESTS
+ help
+ This builds the commoncap KUnit tests.
+
+ KUnit tests run during boot and output the results to the debug log
+ in TAP format (https://testanything.org/). Only useful for kernel devs
+ running KUnit test harness and are not for inclusion into a
+ production build.
+
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
+
source "security/Kconfig.hardening"
endmenu
diff --git a/security/Makefile b/security/Makefile
index 22ff4c8bd8ce..5b1285fde552 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_KEYS) += keys/
# always enable default capabilities
obj-y += commoncap.o
+obj-$(CONFIG_SECURITY_COMMONCAP_KUNIT_TEST) += commoncap_test.o
obj-$(CONFIG_SECURITY) += lsm_syscalls.o
obj-$(CONFIG_MMU) += min_addr.o
diff --git a/security/commoncap.c b/security/commoncap.c
index 6bd4adeb4795..4d0e014ce7cd 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -358,7 +358,12 @@ int cap_inode_killpriv(struct mnt_idmap *idmap, struct dentry *dentry)
return error;
}
+#ifdef CONFIG_SECURITY_COMMONCAP_KUNIT_TEST
+bool rootid_owns_currentns(vfsuid_t rootvfsuid);
+bool rootid_owns_currentns(vfsuid_t rootvfsuid)
+#else
static bool rootid_owns_currentns(vfsuid_t rootvfsuid)
+#endif
{
struct user_namespace *ns;
kuid_t kroot;
diff --git a/security/commoncap_test.c b/security/commoncap_test.c
new file mode 100644
index 000000000000..9757d433d314
--- /dev/null
+++ b/security/commoncap_test.c
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * KUnit tests for commoncap.c security functions
+ *
+ * Tests for security-critical functions in the capability subsystem,
+ * particularly namespace-related capability checks.
+ */
+
+#include <kunit/test.h>
+#include <linux/user_namespace.h>
+#include <linux/uidgid.h>
+#include <linux/module.h>
+
+/* We need to include the actual vfsuid_t definition but avoid the problematic
+ * inline functions in mnt_idmapping.h. Include just the type definitions.
+ */
+#include <linux/types.h>
+
+/* Forward declare the minimal types we need - match the actual kernel definitions */
+struct mnt_idmap;
+typedef struct {
+ uid_t val;
+} vfsuid_t;
+
+/* Minimal macros we need - match kernel definitions from mnt_idmapping.h */
+static inline uid_t __vfsuid_val(vfsuid_t uid)
+{
+ return uid.val;
+}
+
+#define VFSUIDT_INIT(val) ((vfsuid_t){ __kuid_val(val) })
+#define INVALID_VFSUID VFSUIDT_INIT(INVALID_UID)
+
+#ifdef CONFIG_SECURITY_COMMONCAP_KUNIT_TEST
+
+/* Forward declaration - function is exported when KUNIT_TEST is enabled */
+extern bool rootid_owns_currentns(vfsuid_t rootvfsuid);
+
+/**
+ * test_rootid_owns_currentns_init_ns - Test rootid_owns_currentns with init ns
+ *
+ * Verifies that a root ID in the init namespace correctly owns the current
+ * namespace when running in init_user_ns.
+ */
+static void test_rootid_owns_currentns_init_ns(struct kunit *test)
+{
+ vfsuid_t root_vfsuid;
+ kuid_t root_kuid;
+
+ /* Create a root UID in init namespace */
+ root_kuid = KUIDT_INIT(0);
+ root_vfsuid = VFSUIDT_INIT(root_kuid);
+
+ /* In init namespace, root should own current namespace */
+ KUNIT_EXPECT_TRUE(test, rootid_owns_currentns(root_vfsuid));
+}
+
+/**
+ * test_rootid_owns_currentns_invalid - Test rootid_owns_currentns with invalid vfsuid
+ *
+ * Verifies that an invalid vfsuid correctly returns false.
+ */
+static void test_rootid_owns_currentns_invalid(struct kunit *test)
+{
+ vfsuid_t invalid_vfsuid;
+
+ /* Use the predefined invalid vfsuid */
+ invalid_vfsuid = INVALID_VFSUID;
+
+ /* Invalid vfsuid should return false */
+ KUNIT_EXPECT_FALSE(test, rootid_owns_currentns(invalid_vfsuid));
+}
+
+/**
+ * test_rootid_owns_currentns_nonroot - Test rootid_owns_currentns with non-root UID
+ *
+ * Verifies that a non-root UID correctly returns false.
+ */
+static void test_rootid_owns_currentns_nonroot(struct kunit *test)
+{
+ vfsuid_t nonroot_vfsuid;
+ kuid_t nonroot_kuid;
+
+ /* Create a non-root UID */
+ nonroot_kuid = KUIDT_INIT(1000);
+ nonroot_vfsuid = VFSUIDT_INIT(nonroot_kuid);
+
+ /* Non-root UID should return false */
+ KUNIT_EXPECT_FALSE(test, rootid_owns_currentns(nonroot_vfsuid));
+}
+
+static struct kunit_case commoncap_test_cases[] = {
+ KUNIT_CASE(test_rootid_owns_currentns_init_ns),
+ KUNIT_CASE(test_rootid_owns_currentns_invalid),
+ KUNIT_CASE(test_rootid_owns_currentns_nonroot),
+ {}
+};
+
+static struct kunit_suite commoncap_test_suite = {
+ .name = "commoncap",
+ .test_cases = commoncap_test_cases,
+};
+
+kunit_test_suite(commoncap_test_suite);
+
+MODULE_LICENSE("GPL");
+
+#endif /* CONFIG_SECURITY_COMMONCAP_KUNIT_TEST */
+
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] security: provide an inlined static branch for security_inode_permission()
From: Mateusz Guzik @ 2025-11-09 21:52 UTC (permalink / raw)
To: Paul Moore
Cc: casey, keescook, song, andrii, kpsingh, linux-security-module,
linux-fsdevel
In-Reply-To: <CAHC9VhRCvoXrUESCjbxz5Bcxjq8GXLj4GvSoXq+sukdP1cuXNg@mail.gmail.com>
On Sun, Nov 9, 2025 at 10:29 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Sun, Nov 9, 2025 at 2:29 PM Mateusz Guzik <mjguzik@gmail.com> wrote:
> >
> > The routine is executing for every path component during name resolution in
> > vfs and shows up on the profile to the tune of 2% of CPU time in my
> > tests.
> >
> > The only LSMs which install hoooks there are selinux and smack, meaning
> > most installs don't have it and this ends up being a call to do nothing.
>
> Unless you have a reputable survey or analysis to back up claims like
> this, please refrain from making comments like these in commit
> messages. I can't speak to Smack's adoption numbers, but last I
> looked in 2023, and considering only Android since numbers were easy
> to source, SELinux was deployed in enforcing mode on over 3 billion
> systems. Of course I don't have numbers handy for *all* Linux
> systems, and there are some numbers that simply are never going to be
> public, but given the +3 billion Android systems alone, I think there
> is a very real likelihood that there are more systems running SELinux
> than those that are not.
>
Fair, I was mostly thinking stuff like Ubuntu. Phone stuff is not on my radar.
> > While perhaps a more generic mechanism covering all hoooks would be
> > preferred, I implemented a bare minimum version which gets out of the
> > way for my needs.
>
> I'd much rather see a generalized solution than hacks for a small
> number of hooks.
>
I'll ponder about this.
> --
> paul-moore.com
^ permalink raw reply
* Re: [PATCH] security: provide an inlined static branch for security_inode_permission()
From: Paul Moore @ 2025-11-09 21:29 UTC (permalink / raw)
To: Mateusz Guzik
Cc: casey, keescook, song, andrii, kpsingh, linux-security-module,
linux-fsdevel
In-Reply-To: <20251109192940.1334775-1-mjguzik@gmail.com>
On Sun, Nov 9, 2025 at 2:29 PM Mateusz Guzik <mjguzik@gmail.com> wrote:
>
> The routine is executing for every path component during name resolution in
> vfs and shows up on the profile to the tune of 2% of CPU time in my
> tests.
>
> The only LSMs which install hoooks there are selinux and smack, meaning
> most installs don't have it and this ends up being a call to do nothing.
Unless you have a reputable survey or analysis to back up claims like
this, please refrain from making comments like these in commit
messages. I can't speak to Smack's adoption numbers, but last I
looked in 2023, and considering only Android since numbers were easy
to source, SELinux was deployed in enforcing mode on over 3 billion
systems. Of course I don't have numbers handy for *all* Linux
systems, and there are some numbers that simply are never going to be
public, but given the +3 billion Android systems alone, I think there
is a very real likelihood that there are more systems running SELinux
than those that are not.
> While perhaps a more generic mechanism covering all hoooks would be
> preferred, I implemented a bare minimum version which gets out of the
> way for my needs.
I'd much rather see a generalized solution than hacks for a small
number of hooks.
--
paul-moore.com
^ permalink raw reply
* RE: Module signing and post-quantum crypto public key algorithms
From: Elliott, Robert (Servers) @ 2025-11-09 19:30 UTC (permalink / raw)
To: David Howells
Cc: Simo Sorce, James Bottomley, Ignat Korchagin, Herbert Xu,
Stephan Mueller, torvalds@linux-foundation.org, Paul Moore,
Lukas Wunner, Clemens Lang, David Bohannon, Roberto Sassu,
keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <534145.1762588015@warthog.procyon.org.uk>
> -----Original Message-----
> From: David Howells <dhowells@redhat.com>
> Sent: Saturday, November 8, 2025 1:47 AM
> To: Elliott, Robert (Servers) <elliott@hpe.com>
> Cc: dhowells@redhat.com; Simo Sorce <simo@redhat.com>; James Bottomley
> <James.Bottomley@HansenPartnership.com>; Ignat Korchagin
> <ignat@cloudflare.com>; Herbert Xu <herbert@gondor.apana.org.au>;
> Stephan Mueller <smueller@chronox.de>; torvalds@linux-foundation.org;
> Paul Moore <paul@paul-moore.com>; Lukas Wunner <lukas@wunner.de>;
> Clemens Lang <cllang@redhat.com>; David Bohannon <dbohanno@redhat.com>;
> Roberto Sassu <roberto.sassu@huawei.com>; keyrings@vger.kernel.org;
> linux-crypto@vger.kernel.org; linux-security-module@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: Module signing and post-quantum crypto public key
> algorithms
>
> Elliott, Robert (Servers) <elliott@hpe.com> wrote:
>
> > The traditional signature would use whatever algorithm is used today.
> > Legacy verifiers would only check that.
>
> Would there be any legacy verifiers? Kernel modules are generally tied
> to the kernel version for which they were compiled. Granted there are
> things like the wifi regulatory stuff that are also signed.
If the system building and signing a module doesn't have OpenSSL 3.5 yet,
it can only provide a legacy signature. If the kernel is only looking
for a composite by default, a kernel command line allowing a legacy
signature to be accepted would help the transition.
Userspace tools can check signatures, but I don't know if that is done
in any non-developer situations. I did it manually while testing x86
optimized crypto module changes a few years ago.
If and when a distro is confident there are no userspace tools, it could
stop signing with legacy signatures.
> But note also, PKCS#7 supports multiple independent signatures in a
> single object. The kernel will handle this already. At least one
> signature must be verifiable and none must be blacklisted.
Yes, I think that makes multiple signatures viable.
> I assume that the main aim of using a composite algorithm is to share
> the result of the content hash - but in this case only the
> authenticatedAttributes are going to be hashed for the signature, and
> that's relatively small.
The composite motivation is to provide some protection if someone
discovers a basic flaw in the PQC algorithm. If quantum computers
haven't arrived yet to break the traditional algorithm, the
composite still proves validity.
The CMS and OpenPGP constructions ensure that the signatures are
non-separable; an attacker cannot strip off the strong one and leave
the broken one. The verifier always runs both algorithms (unlike
the current OR policy with multiple signatures).
^ permalink raw reply
* [PATCH] security: provide an inlined static branch for security_inode_permission()
From: Mateusz Guzik @ 2025-11-09 19:29 UTC (permalink / raw)
To: paul
Cc: casey, keescook, song, andrii, kpsingh, linux-security-module,
linux-fsdevel, Mateusz Guzik
The routine is executing for every path component during name resolution in
vfs and shows up on the profile to the tune of 2% of CPU time in my
tests.
The only LSMs which install hoooks there are selinux and smack, meaning
most installs don't have it and this ends up being a call to do nothing.
While perhaps a more generic mechanism covering all hoooks would be
preferred, I implemented a bare minimum version which gets out of the
way for my needs.
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
---
include/linux/security.h | 11 ++++++++++-
security/security.c | 12 ++++++++++--
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index 92ac3f27b973..0ce1d73167ed 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -68,6 +68,8 @@ struct watch;
struct watch_notification;
struct lsm_ctx;
+DECLARE_STATIC_KEY_FALSE(security_inode_permission_has_hooks);
+
/* Default (no) options for the capable function */
#define CAP_OPT_NONE 0x0
/* If capable should audit the security request */
@@ -421,7 +423,14 @@ int security_inode_rename(struct inode *old_dir, struct dentry *old_dentry,
int security_inode_readlink(struct dentry *dentry);
int security_inode_follow_link(struct dentry *dentry, struct inode *inode,
bool rcu);
-int security_inode_permission(struct inode *inode, int mask);
+int __security_inode_permission(struct inode *inode, int mask);
+static inline int security_inode_permission(struct inode *inode, int mask)
+{
+ if (static_branch_unlikely(&security_inode_permission_has_hooks))
+ return __security_inode_permission(inode, mask);
+ return 0;
+}
+
int security_inode_setattr(struct mnt_idmap *idmap,
struct dentry *dentry, struct iattr *attr);
void security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry,
diff --git a/security/security.c b/security/security.c
index 4d3c03a4524c..e879f034a77c 100644
--- a/security/security.c
+++ b/security/security.c
@@ -51,6 +51,8 @@ do { \
#define LSM_DEFINE_UNROLL(M, ...) UNROLL(MAX_LSM_COUNT, M, __VA_ARGS__)
+DEFINE_STATIC_KEY_FALSE(security_inode_permission_has_hooks);
+
/*
* These are descriptions of the reasons that can be passed to the
* security_locked_down() LSM hook. Placing this array here allows
@@ -639,6 +641,12 @@ void __init security_add_hooks(struct security_hook_list *hooks, int count,
lsm_static_call_init(&hooks[i]);
}
+ if (static_key_enabled(&static_calls_table.inode_permission->active->key)) {
+ if (!static_key_enabled(&security_inode_permission_has_hooks.key)) {
+ static_branch_enable(&security_inode_permission_has_hooks);
+ }
+ }
+
/*
* Don't try to append during early_security_init(), we'll come back
* and fix this up afterwards.
@@ -2343,7 +2351,7 @@ int security_inode_follow_link(struct dentry *dentry, struct inode *inode,
}
/**
- * security_inode_permission() - Check if accessing an inode is allowed
+ * __security_inode_permission() - Check if accessing an inode is allowed
* @inode: inode
* @mask: access mask
*
@@ -2356,7 +2364,7 @@ int security_inode_follow_link(struct dentry *dentry, struct inode *inode,
*
* Return: Returns 0 if permission is granted.
*/
-int security_inode_permission(struct inode *inode, int mask)
+int __security_inode_permission(struct inode *inode, int mask)
{
if (unlikely(IS_PRIVATE(inode)))
return 0;
--
2.48.1
^ permalink raw reply related
* [RFC PATCH 3/3] ptrace: ensure PTRACE_EVENT_EXIT won't stop if the tracee is killed by exec
From: Oleg Nesterov @ 2025-11-09 17:16 UTC (permalink / raw)
To: Bernd Edlinger, Linus Torvalds, Dmitry Levin
Cc: Alexander Viro, Alexey Dobriyan, Kees Cook, Andy Lutomirski,
Will Drewry, Christian Brauner, Andrew Morton, Michal Hocko,
Serge Hallyn, James Morris, Randy Dunlap, Suren Baghdasaryan,
Yafang Shao, Helge Deller, Eric W. Biederman, Adrian Reber,
Thomas Gleixner, Jens Axboe, Alexei Starovoitov,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest, linux-mm, linux-security-module, tiozhang,
Luis Chamberlain, Paulo Alcantara (SUSE), Sergey Senozhatsky,
Frederic Weisbecker, YueHaibing, Paul Moore, Aleksa Sarai,
Stefan Roesch, Chao Yu, xu xin, Jeff Layton, Jan Kara,
David Hildenbrand, Dave Chinner, Shuah Khan, Elena Reshetova,
David Windsor, Mateusz Guzik, Ard Biesheuvel,
Joel Fernandes (Google), Matthew Wilcox (Oracle),
Hans Liljestrand, Penglei Jiang, Lorenzo Stoakes, Adrian Ratiu,
Ingo Molnar, Peter Zijlstra (Intel), Cyrill Gorcunov,
Eric Dumazet
In-Reply-To: <aRDL3HOB21pMVMWC@redhat.com>
The previous patch fixed the deadlock when mt-exec waits for debugger
which should reap a zombie thread, but we can hit the same problem if
the killed sub-thread stops in ptrace_event(PTRACE_EVENT_EXIT). Change
ptrace_stop() to check signal->group_exit_task.
This is a user-visible change. But hopefully it can't break anything.
Note that the semantics of PTRACE_EVENT_EXIT was never really defined,
it depends on /dev/random. Just for example, currently a sub-thread
killed by exec will stop, but if it exits on its own and races with
exec it will not stop, so nobody can rely on PTRACE_EVENT_EXIT anyway.
We really need to finally define what PTRACE_EVENT_EXIT should actually
do, but this needs other changes.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
kernel/signal.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index 334212044940..59f61e07905b 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2376,6 +2376,10 @@ static int ptrace_stop(int exit_code, int why, unsigned long message,
if (!current->ptrace || __fatal_signal_pending(current))
return exit_code;
+ /* de_thread() -> wait_for_notify_count() waits for us */
+ if (current->signal->group_exec_task)
+ return exit_code;
+
set_special_state(TASK_TRACED);
current->jobctl |= JOBCTL_TRACED;
--
2.25.1.362.g51ebf55
^ permalink raw reply related
* [RFC PATCH 2/3] exec: don't wait for zombie threads with cred_guard_mutex held
From: Oleg Nesterov @ 2025-11-09 17:15 UTC (permalink / raw)
To: Bernd Edlinger, Linus Torvalds, Dmitry Levin
Cc: Alexander Viro, Alexey Dobriyan, Kees Cook, Andy Lutomirski,
Will Drewry, Christian Brauner, Andrew Morton, Michal Hocko,
Serge Hallyn, James Morris, Randy Dunlap, Suren Baghdasaryan,
Yafang Shao, Helge Deller, Eric W. Biederman, Adrian Reber,
Thomas Gleixner, Jens Axboe, Alexei Starovoitov,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest, linux-mm, linux-security-module, tiozhang,
Luis Chamberlain, Paulo Alcantara (SUSE), Sergey Senozhatsky,
Frederic Weisbecker, YueHaibing, Paul Moore, Aleksa Sarai,
Stefan Roesch, Chao Yu, xu xin, Jeff Layton, Jan Kara,
David Hildenbrand, Dave Chinner, Shuah Khan, Elena Reshetova,
David Windsor, Mateusz Guzik, Ard Biesheuvel,
Joel Fernandes (Google), Matthew Wilcox (Oracle),
Hans Liljestrand, Penglei Jiang, Lorenzo Stoakes, Adrian Ratiu,
Ingo Molnar, Peter Zijlstra (Intel), Cyrill Gorcunov,
Eric Dumazet
In-Reply-To: <aRDL3HOB21pMVMWC@redhat.com>
This simple program
#include <unistd.h>
#include <signal.h>
#include <sys/ptrace.h>
#include <pthread.h>
void *thread(void *arg)
{
ptrace(PTRACE_TRACEME, 0,0,0);
return NULL;
}
int main(void)
{
int pid = fork();
if (!pid) {
pthread_t pt;
pthread_create(&pt, NULL, thread, NULL);
pthread_join(pt, NULL);
execlp("echo", "echo", "passed", NULL);
}
sleep(1);
ptrace(PTRACE_ATTACH, pid, 0,0);
kill(pid, SIGCONT);
return 0;
}
hangs because de_thread() waits for debugger which should release the killed
thread with cred_guard_mutex held, while the debugger sleeps waiting for the
same mutex. Not really that bad, the tracer can be killed, but still this is
a bug and people hit it in practice.
With this patch:
- de_thread() waits until all the sub-threads pass exit_notify() and
become zombies.
- setup_new_exec() waits until all the sub-threads are reaped without
cred_guard_mutex held.
- unshare_sighand() and flush_signal_handlers() are moved from
begin_new_exec() to setup_new_exec(), we can't call them until all
sub-threads go away.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/exec.c | 140 +++++++++++++++++++++++-------------------------
kernel/exit.c | 9 ++--
kernel/signal.c | 2 +-
3 files changed, 71 insertions(+), 80 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 136a7ab5d91c..2bac7deb9a98 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -905,42 +905,56 @@ static int exec_mmap(struct mm_struct *mm)
return 0;
}
-static int de_thread(struct task_struct *tsk)
+static int kill_sub_threads(struct task_struct *tsk)
{
struct signal_struct *sig = tsk->signal;
- struct sighand_struct *oldsighand = tsk->sighand;
- spinlock_t *lock = &oldsighand->siglock;
-
- if (thread_group_empty(tsk))
- goto no_thread_group;
+ int err = -EINTR;
- /*
- * Kill all other threads in the thread group.
- */
- spin_lock_irq(lock);
- if ((sig->flags & SIGNAL_GROUP_EXIT) || sig->group_exec_task) {
- /*
- * Another group action in progress, just
- * return so that the signal is processed.
- */
- spin_unlock_irq(lock);
- return -EAGAIN;
+ read_lock(&tasklist_lock);
+ spin_lock_irq(&tsk->sighand->siglock);
+ if (!((sig->flags & SIGNAL_GROUP_EXIT) || sig->group_exec_task)) {
+ sig->group_exec_task = tsk;
+ sig->notify_count = -zap_other_threads(tsk);
+ err = 0;
}
+ spin_unlock_irq(&tsk->sighand->siglock);
+ read_unlock(&tasklist_lock);
- sig->group_exec_task = tsk;
- sig->notify_count = zap_other_threads(tsk);
- if (!thread_group_leader(tsk))
- sig->notify_count--;
+ return err;
+}
- while (sig->notify_count) {
- __set_current_state(TASK_KILLABLE);
- spin_unlock_irq(lock);
- schedule();
+static int wait_for_notify_count(struct task_struct *tsk)
+{
+ for (;;) {
if (__fatal_signal_pending(tsk))
- goto killed;
- spin_lock_irq(lock);
+ return -EINTR;
+ set_current_state(TASK_KILLABLE);
+ if (!tsk->signal->notify_count)
+ break;
+ schedule();
}
- spin_unlock_irq(lock);
+ __set_current_state(TASK_RUNNING);
+ return 0;
+}
+
+static void clear_group_exec_task(struct task_struct *tsk)
+{
+ struct signal_struct *sig = tsk->signal;
+
+ /* protects against exit_notify() and __exit_signal() */
+ read_lock(&tasklist_lock);
+ sig->group_exec_task = NULL;
+ sig->notify_count = 0;
+ read_unlock(&tasklist_lock);
+}
+
+static int de_thread(struct task_struct *tsk)
+{
+ if (thread_group_empty(tsk))
+ goto no_thread_group;
+
+ if (kill_sub_threads(tsk) || wait_for_notify_count(tsk))
+ return -EINTR;
/*
* At this point all other threads have exited, all we have to
@@ -948,26 +962,10 @@ static int de_thread(struct task_struct *tsk)
* and to assume its PID:
*/
if (!thread_group_leader(tsk)) {
- struct task_struct *leader = tsk->group_leader;
-
- for (;;) {
- cgroup_threadgroup_change_begin(tsk);
- write_lock_irq(&tasklist_lock);
- /*
- * Do this under tasklist_lock to ensure that
- * exit_notify() can't miss ->group_exec_task
- */
- sig->notify_count = -1;
- if (likely(leader->exit_state))
- break;
- __set_current_state(TASK_KILLABLE);
- write_unlock_irq(&tasklist_lock);
- cgroup_threadgroup_change_end(tsk);
- schedule();
- if (__fatal_signal_pending(tsk))
- goto killed;
- }
+ struct task_struct *leader = tsk->group_leader, *t;
+ cgroup_threadgroup_change_begin(tsk);
+ write_lock_irq(&tasklist_lock);
/*
* The only record we have of the real-time age of a
* process, regardless of execs it's done, is start_time.
@@ -1000,8 +998,8 @@ static int de_thread(struct task_struct *tsk)
list_replace_rcu(&leader->tasks, &tsk->tasks);
list_replace_init(&leader->sibling, &tsk->sibling);
- tsk->group_leader = tsk;
- leader->group_leader = tsk;
+ for_each_thread(tsk, t)
+ t->group_leader = tsk;
tsk->exit_signal = SIGCHLD;
leader->exit_signal = -1;
@@ -1021,23 +1019,11 @@ static int de_thread(struct task_struct *tsk)
release_task(leader);
}
- sig->group_exec_task = NULL;
- sig->notify_count = 0;
-
no_thread_group:
/* we have changed execution domain */
tsk->exit_signal = SIGCHLD;
-
BUG_ON(!thread_group_leader(tsk));
return 0;
-
-killed:
- /* protects against exit_notify() and __exit_signal() */
- read_lock(&tasklist_lock);
- sig->group_exec_task = NULL;
- sig->notify_count = 0;
- read_unlock(&tasklist_lock);
- return -EAGAIN;
}
@@ -1171,13 +1157,6 @@ int begin_new_exec(struct linux_binprm * bprm)
flush_itimer_signals();
#endif
- /*
- * Make the signal table private.
- */
- retval = unshare_sighand(me);
- if (retval)
- goto out_unlock;
-
me->flags &= ~(PF_RANDOMIZE | PF_FORKNOEXEC |
PF_NOFREEZE | PF_NO_SETAFFINITY);
flush_thread();
@@ -1249,7 +1228,6 @@ int begin_new_exec(struct linux_binprm * bprm)
/* An exec changes our domain. We are no longer part of the thread
group */
WRITE_ONCE(me->self_exec_id, me->self_exec_id + 1);
- flush_signal_handlers(me, 0);
retval = set_cred_ucounts(bprm->cred);
if (retval < 0)
@@ -1293,8 +1271,9 @@ int begin_new_exec(struct linux_binprm * bprm)
up_write(&me->signal->exec_update_lock);
if (!bprm->cred)
mutex_unlock(&me->signal->cred_guard_mutex);
-
out:
+ if (me->signal->group_exec_task == me)
+ clear_group_exec_task(me);
return retval;
}
EXPORT_SYMBOL(begin_new_exec);
@@ -1325,6 +1304,8 @@ int setup_new_exec(struct linux_binprm * bprm)
{
/* Setup things that can depend upon the personality */
struct task_struct *me = current;
+ struct signal_struct *sig = me->signal;
+ int err = 0;
arch_pick_mmap_layout(me->mm, &bprm->rlim_stack);
@@ -1335,10 +1316,23 @@ int setup_new_exec(struct linux_binprm * bprm)
* some architectures like powerpc
*/
me->mm->task_size = TASK_SIZE;
- up_write(&me->signal->exec_update_lock);
- mutex_unlock(&me->signal->cred_guard_mutex);
+ up_write(&sig->exec_update_lock);
+ mutex_unlock(&sig->cred_guard_mutex);
- return 0;
+ if (sig->group_exec_task) {
+ spin_lock_irq(&me->sighand->siglock);
+ sig->notify_count = sig->nr_threads - 1;
+ spin_unlock_irq(&me->sighand->siglock);
+
+ err = wait_for_notify_count(me);
+ clear_group_exec_task(me);
+ }
+
+ if (!err)
+ err = unshare_sighand(me);
+ if (!err)
+ flush_signal_handlers(me, 0);
+ return err;
}
EXPORT_SYMBOL(setup_new_exec);
diff --git a/kernel/exit.c b/kernel/exit.c
index f041f0c05ebb..bcde78c97253 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -178,10 +178,7 @@ static void __exit_signal(struct release_task_post *post, struct task_struct *ts
tty = sig->tty;
sig->tty = NULL;
} else {
- /*
- * If there is any task waiting for the group exit
- * then notify it:
- */
+ /* mt-exec, setup_new_exec() -> wait_for_notify_count() */
if (sig->notify_count > 0 && !--sig->notify_count)
wake_up_process(sig->group_exec_task);
@@ -766,8 +763,8 @@ static void exit_notify(struct task_struct *tsk, int group_dead)
list_add(&tsk->ptrace_entry, &dead);
}
- /* mt-exec, de_thread() is waiting for group leader */
- if (unlikely(tsk->signal->notify_count < 0))
+ /* mt-exec, de_thread() -> wait_for_notify_count() */
+ if (tsk->signal->notify_count < 0 && !++tsk->signal->notify_count)
wake_up_process(tsk->signal->group_exec_task);
write_unlock_irq(&tasklist_lock);
diff --git a/kernel/signal.c b/kernel/signal.c
index fe9190d84f28..334212044940 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1343,13 +1343,13 @@ int zap_other_threads(struct task_struct *p)
for_other_threads(p, t) {
task_clear_jobctl_pending(t, JOBCTL_PENDING_MASK);
- count++;
/* Don't bother with already dead threads */
if (t->exit_state)
continue;
sigaddset(&t->pending.signal, SIGKILL);
signal_wake_up(t, 1);
+ count++;
}
return count;
--
2.25.1.362.g51ebf55
^ permalink raw reply related
* [RFC PATCH 1/3] exec: make setup_new_exec() return int
From: Oleg Nesterov @ 2025-11-09 17:14 UTC (permalink / raw)
To: Bernd Edlinger, Linus Torvalds, Dmitry Levin
Cc: Alexander Viro, Alexey Dobriyan, Kees Cook, Andy Lutomirski,
Will Drewry, Christian Brauner, Andrew Morton, Michal Hocko,
Serge Hallyn, James Morris, Randy Dunlap, Suren Baghdasaryan,
Yafang Shao, Helge Deller, Eric W. Biederman, Adrian Reber,
Thomas Gleixner, Jens Axboe, Alexei Starovoitov,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest, linux-mm, linux-security-module, tiozhang,
Luis Chamberlain, Paulo Alcantara (SUSE), Sergey Senozhatsky,
Frederic Weisbecker, YueHaibing, Paul Moore, Aleksa Sarai,
Stefan Roesch, Chao Yu, xu xin, Jeff Layton, Jan Kara,
David Hildenbrand, Dave Chinner, Shuah Khan, Elena Reshetova,
David Windsor, Mateusz Guzik, Ard Biesheuvel,
Joel Fernandes (Google), Matthew Wilcox (Oracle),
Hans Liljestrand, Penglei Jiang, Lorenzo Stoakes, Adrian Ratiu,
Ingo Molnar, Peter Zijlstra (Intel), Cyrill Gorcunov,
Eric Dumazet
In-Reply-To: <aRDL3HOB21pMVMWC@redhat.com>
Preparation. After the next change setup_new_exec() can fail.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/binfmt_elf.c | 4 +++-
fs/binfmt_elf_fdpic.c | 4 +++-
fs/binfmt_flat.c | 4 +++-
fs/exec.c | 4 +++-
include/linux/binfmts.h | 2 +-
5 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index e4653bb99946..8a38689ae4b0 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1021,7 +1021,9 @@ static int load_elf_binary(struct linux_binprm *bprm)
if (!(current->personality & ADDR_NO_RANDOMIZE) && snapshot_randomize_va_space)
current->flags |= PF_RANDOMIZE;
- setup_new_exec(bprm);
+ retval = setup_new_exec(bprm);
+ if (retval)
+ goto out_free_dentry;
/* Do this so that we can load the interpreter, if need be. We will
change some of these later */
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 48fd2de3bca0..7ad98b8132fc 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -351,7 +351,9 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm)
if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
current->personality |= READ_IMPLIES_EXEC;
- setup_new_exec(bprm);
+ retval = setup_new_exec(bprm);
+ if (retval)
+ goto error;
set_binfmt(&elf_fdpic_format);
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index b5b5ca1a44f7..78e9ca128ea7 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -512,7 +512,9 @@ static int load_flat_file(struct linux_binprm *bprm,
/* OK, This is the point of no return */
set_personality(PER_LINUX_32BIT);
- setup_new_exec(bprm);
+ ret = setup_new_exec(bprm);
+ if (ret)
+ goto err;
/*
* calculate the extra space we need to map in
diff --git a/fs/exec.c b/fs/exec.c
index 6b70c6726d31..136a7ab5d91c 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1321,7 +1321,7 @@ void would_dump(struct linux_binprm *bprm, struct file *file)
}
EXPORT_SYMBOL(would_dump);
-void setup_new_exec(struct linux_binprm * bprm)
+int setup_new_exec(struct linux_binprm * bprm)
{
/* Setup things that can depend upon the personality */
struct task_struct *me = current;
@@ -1337,6 +1337,8 @@ void setup_new_exec(struct linux_binprm * bprm)
me->mm->task_size = TASK_SIZE;
up_write(&me->signal->exec_update_lock);
mutex_unlock(&me->signal->cred_guard_mutex);
+
+ return 0;
}
EXPORT_SYMBOL(setup_new_exec);
diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
index 65abd5ab8836..678b7525ac5a 100644
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@ -123,7 +123,7 @@ extern void unregister_binfmt(struct linux_binfmt *);
extern int __must_check remove_arg_zero(struct linux_binprm *);
extern int begin_new_exec(struct linux_binprm * bprm);
-extern void setup_new_exec(struct linux_binprm * bprm);
+extern int setup_new_exec(struct linux_binprm * bprm);
extern void finalize_exec(struct linux_binprm *bprm);
extern void would_dump(struct linux_binprm *, struct file *);
--
2.25.1.362.g51ebf55
^ permalink raw reply related
* [RFC PATCH 0/3] mt-exec: fix deadlock with ptrace_attach()
From: Oleg Nesterov @ 2025-11-09 17:14 UTC (permalink / raw)
To: Bernd Edlinger, Linus Torvalds, Dmitry Levin
Cc: Alexander Viro, Alexey Dobriyan, Kees Cook, Andy Lutomirski,
Will Drewry, Christian Brauner, Andrew Morton, Michal Hocko,
Serge Hallyn, James Morris, Randy Dunlap, Suren Baghdasaryan,
Yafang Shao, Helge Deller, Eric W. Biederman, Adrian Reber,
Thomas Gleixner, Jens Axboe, Alexei Starovoitov,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest, linux-mm, linux-security-module, tiozhang,
Luis Chamberlain, Paulo Alcantara (SUSE), Sergey Senozhatsky,
Frederic Weisbecker, YueHaibing, Paul Moore, Aleksa Sarai,
Stefan Roesch, Chao Yu, xu xin, Jeff Layton, Jan Kara,
David Hildenbrand, Dave Chinner, Shuah Khan, Elena Reshetova,
David Windsor, Mateusz Guzik, Ard Biesheuvel,
Joel Fernandes (Google), Matthew Wilcox (Oracle),
Hans Liljestrand, Penglei Jiang, Lorenzo Stoakes, Adrian Ratiu,
Ingo Molnar, Peter Zijlstra (Intel), Cyrill Gorcunov,
Eric Dumazet
In-Reply-To: <GV2PPF74270EBEE9EF78827D73D3D7212F7E432A@GV2PPF74270EBEE.EURP195.PROD.OUTLOOK.COM>
Not for inclusion yet. 2/2 is untested, incomplete, possibly buggy.
But could you review at least the intent? Do you see any problem with
this approach?
This problem is very, very old. It seems that nobody can suggest a
simple/clean fix...
Oleg.
---
fs/binfmt_elf.c | 4 +-
fs/binfmt_elf_fdpic.c | 4 +-
fs/binfmt_flat.c | 4 +-
fs/exec.c | 142 +++++++++++++++++++++++-------------------------
include/linux/binfmts.h | 2 +-
kernel/exit.c | 9 +--
kernel/signal.c | 6 +-
7 files changed, 87 insertions(+), 84 deletions(-)
^ permalink raw reply
* Re: [syzbot] [fs?] WARNING in destroy_super_work
From: syzbot @ 2025-11-09 14:11 UTC (permalink / raw)
To: akpm, anna-maria, bpf, brauner, bsegall, cgroups, david,
dietmar.eggemann, frederic, hannes, jack, jsavitz, juri.lelli,
kees, liam.howlett, linux-fsdevel, linux-kernel, linux-mm,
linux-security-module, lorenzo.stoakes, mgorman, mhocko, mingo,
mjguzik, mkoutny, oleg, paul, peterz, rostedt, rppt, sergeh,
surenb, syzkaller-bugs, tglx, tj, vbabka, vincent.guittot, viro,
vschneid
In-Reply-To: <20251109-lesung-erkaufen-476f6fb00b1b@brauner>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+1957b26299cf3ff7890c@syzkaller.appspotmail.com
Tested-by: syzbot+1957b26299cf3ff7890c@syzkaller.appspotmail.com
Tested on:
commit: 241462cd ns: fixes for namespace iteration and active ..
git tree: https://github.com/brauner/linux.git namespace-6.19.fixes
console output: https://syzkaller.appspot.com/x/log.txt?x=11e1517c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f1b1a45727d1f117
dashboard link: https://syzkaller.appspot.com/bug?extid=1957b26299cf3ff7890c
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* Re: [syzbot] [fs?] WARNING in destroy_super_work
From: Christian Brauner @ 2025-11-09 13:39 UTC (permalink / raw)
To: syzbot
Cc: Liam.Howlett, akpm, anna-maria, bpf, bsegall, cgroups, david,
dietmar.eggemann, frederic, hannes, jack, jsavitz, juri.lelli,
kees, linux-fsdevel, linux-kernel, linux-mm,
linux-security-module, lorenzo.stoakes, mgorman, mhocko, mingo,
mjguzik, mkoutny, oleg, paul, peterz, rostedt, rppt, sergeh,
surenb, syzkaller-bugs, tglx, tj, vbabka, vincent.guittot, viro,
vschneid
In-Reply-To: <690da04f.a70a0220.22f260.0027.GAE@google.com>
On Thu, Nov 06, 2025 at 11:31:27PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 982312090977 Add linux-next specific files for 20251103
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=17b2932f980000
> kernel config: https://syzkaller.appspot.com/x/.config?x=43cc0e31558cb527
> dashboard link: https://syzkaller.appspot.com/bug?extid=1957b26299cf3ff7890c
> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1347817c580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/40058f8a830c/disk-98231209.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/1d7f42e8639f/vmlinux-98231209.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/d8bb0284f393/bzImage-98231209.xz
>
> The issue was bisected to:
>
> commit 3c9820d5c64aeaadea7ffe3a6bb99d019a5ff46a
> Author: Christian Brauner <brauner@kernel.org>
> Date: Wed Oct 29 12:20:24 2025 +0000
>
> ns: add active reference count
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=101e9bcd980000
> final oops: https://syzkaller.appspot.com/x/report.txt?x=121e9bcd980000
> console output: https://syzkaller.appspot.com/x/log.txt?x=141e9bcd980000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+1957b26299cf3ff7890c@syzkaller.appspotmail.com
> Fixes: 3c9820d5c64a ("ns: add active reference count")
#syz test: https://github.com/brauner/linux.git namespace-6.19.fixes
^ permalink raw reply
* Re: [syzbot] [fs?] WARNING in nsproxy_ns_active_put
From: syzbot @ 2025-11-09 8:24 UTC (permalink / raw)
To: Liam.Howlett, Liam.Howlett, akpm, bpf, brauner, bsegall, david,
dietmar.eggemann, jack, jsavitz, juri.lelli, kartikey406, kees,
linux-fsdevel, linux-kernel, linux-mm, linux-security-module,
lorenzo.stoakes, mgorman, mhocko, mingo, mjguzik, oleg, paul,
peterz, rostedt, rppt, sergeh, surenb, syzkaller-bugs, vbabka,
vincent.guittot, viro, vschneid
In-Reply-To: <690bfb9e.050a0220.2e3c35.0013.GAE@google.com>
syzbot has bisected this issue to:
commit 3a18f809184bc5a1cfad7cde5b8b026e2ff61587
Author: Christian Brauner <brauner@kernel.org>
Date: Wed Oct 29 12:20:24 2025 +0000
ns: add active reference count
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11a350b4580000
start commit: 9c0826a5d9aa Add linux-next specific files for 20251107
git tree: linux-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=13a350b4580000
console output: https://syzkaller.appspot.com/x/log.txt?x=15a350b4580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f2ebeee52bf052b8
dashboard link: https://syzkaller.appspot.com/bug?extid=0b2e79f91ff6579bfa5b
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1639d084580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1625aa92580000
Reported-by: syzbot+0b2e79f91ff6579bfa5b@syzkaller.appspotmail.com
Fixes: 3a18f809184b ("ns: add active reference count")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [PATCH] KEYS: encrypted: Return early on allocation failure and drop goto
From: Jarkko Sakkinen @ 2025-11-09 4:47 UTC (permalink / raw)
To: Thorsten Blum
Cc: Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, linux-integrity, keyrings, linux-security-module,
linux-kernel
In-Reply-To: <20251029163157.119000-1-thorsten.blum@linux.dev>
On Wed, Oct 29, 2025 at 05:31:56PM +0100, Thorsten Blum wrote:
> Return ERR_PTR(-ENOMEM) immediately if memory allocation fails, instead
> of using goto and returning a NULL pointer, and remove the now-unused
> 'out' label.
>
> At the call site, check 'ascii_buf' with IS_ERR() and propagate the
> error code returned by datablob_format().
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> security/keys/encrypted-keys/encrypted.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
> index be1f2118447c..25df00b7dbe9 100644
> --- a/security/keys/encrypted-keys/encrypted.c
> +++ b/security/keys/encrypted-keys/encrypted.c
> @@ -276,7 +276,7 @@ static char *datablob_format(struct encrypted_key_payload *epayload,
>
> ascii_buf = kmalloc(asciiblob_len + 1, GFP_KERNEL);
> if (!ascii_buf)
> - goto out;
> + return ERR_PTR(-ENOMEM);
>
> ascii_buf[asciiblob_len] = '\0';
>
> @@ -288,7 +288,6 @@ static char *datablob_format(struct encrypted_key_payload *epayload,
> bufp = &ascii_buf[len];
> for (i = 0; i < (asciiblob_len - len) / 2; i++)
> bufp = hex_byte_pack(bufp, iv[i]);
> -out:
> return ascii_buf;
> }
>
> @@ -932,8 +931,8 @@ static long encrypted_read(const struct key *key, char *buffer,
> goto out;
>
> ascii_buf = datablob_format(epayload, asciiblob_len);
> - if (!ascii_buf) {
> - ret = -ENOMEM;
> + if (IS_ERR(ascii_buf)) {
> + ret = PTR_ERR(ascii_buf);
> goto out;
> }
>
> --
> 2.51.0
>
No thank you as this does not really fix anything.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: Remove the ad-hoc compilation flag CAAM_DEBUG
From: Jarkko Sakkinen @ 2025-11-09 4:44 UTC (permalink / raw)
To: Ye Bin
Cc: a.fatoum, kernel, James.Bottomley, zohar, dhowells, paul, jmorris,
serge, linux-integrity, keyrings, linux-security-module, yebin10
In-Reply-To: <20251028132254.841715-1-yebin@huaweicloud.com>
On Tue, Oct 28, 2025 at 09:22:54PM +0800, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
>
> Fix the broken design based on Jarkko Sakkinen's suggestions as follows:
>
> 1. Remove the ad-hoc compilation flag (i.e., CAAM_DEBUG).
> 2. Substitute pr_info calls with pr_debug calls.
>
> Closes: https://patchwork.kernel.org/project/linux-integrity/patch/20251024061153.61470-1-yebin@huaweicloud.com/
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
> security/keys/trusted-keys/trusted_caam.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
> index 601943ce0d60..c903ee7328ca 100644
> --- a/security/keys/trusted-keys/trusted_caam.c
> +++ b/security/keys/trusted-keys/trusted_caam.c
> @@ -28,16 +28,10 @@ static const match_table_t key_tokens = {
> {opt_err, NULL}
> };
>
> -#ifdef CAAM_DEBUG
> static inline void dump_options(const struct caam_pkey_info *pkey_info)
> {
> - pr_info("key encryption algo %d\n", pkey_info->key_enc_algo);
> + pr_debug("key encryption algo %d\n", pkey_info->key_enc_algo);
> }
> -#else
> -static inline void dump_options(const struct caam_pkey_info *pkey_info)
> -{
> -}
> -#endif
>
> static int get_pkey_options(char *c,
> struct caam_pkey_info *pkey_info)
> --
> 2.34.1
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: Module signing and post-quantum crypto public key algorithms
From: David Howells @ 2025-11-08 7:46 UTC (permalink / raw)
To: Elliott, Robert (Servers)
Cc: dhowells, Simo Sorce, James Bottomley, Ignat Korchagin,
Herbert Xu, Stephan Mueller, torvalds@linux-foundation.org,
Paul Moore, Lukas Wunner, Clemens Lang, David Bohannon,
Roberto Sassu, keyrings@vger.kernel.org,
linux-crypto@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <IA4PR84MB4011FE5ABA934DEF08F1A263ABC3A@IA4PR84MB4011.NAMPRD84.PROD.OUTLOOK.COM>
Elliott, Robert (Servers) <elliott@hpe.com> wrote:
> The traditional signature would use whatever algorithm is used today.
> Legacy verifiers would only check that.
Would there be any legacy verifiers? Kernel modules are generally tied to the
kernel version for which they were compiled. Granted there are things like
the wifi regulatory stuff that are also signed.
But note also, PKCS#7 supports multiple independent signatures in a single
object. The kernel will handle this already. At least one signature must be
verifiable and none must be blacklisted.
I assume that the main aim of using a composite algorithm is to share the
result of the content hash - but in this case only the authenticatedAttributes
are going to be hashed for the signature, and that's relatively small.
David
^ permalink raw reply
* RE: Module signing and post-quantum crypto public key algorithms
From: Elliott, Robert (Servers) @ 2025-11-07 23:10 UTC (permalink / raw)
To: Simo Sorce, James Bottomley, Ignat Korchagin, David Howells
Cc: Herbert Xu, Stephan Mueller, torvalds@linux-foundation.org,
Paul Moore, Lukas Wunner, Clemens Lang, David Bohannon,
Roberto Sassu, keyrings@vger.kernel.org,
linux-crypto@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <3d650cc9ff07462e5c55cc3d9c0da72a3f2c5df2.camel@redhat.com>
> -----Original Message-----
> From: Simo Sorce <simo@redhat.com>
> Sent: Monday, June 16, 2025 12:27 PM
> Subject: Re: Module signing and post-quantum crypto public key
> algorithms
>
...
> Of course we can decide to hedge *all bets* and move to a composed
> signature (both a classic and a PQ one), in which case I would suggest
> looking into signatures that use ML-DSA-87 + Ed448 or ML-DSA-87 + P-521
> ,ideally disjoint, with a kernel policy that can decide which (or both)
> needs to be valid/checked so that the policy can be changed quickly via
> configuration if any of the signature is broken.
>
> This will allow for fears of Lattice not being vetted enough to be
> managed as well as increasing the strength of the classic option, while
> maintaining key and signature sizes manageable.
I like the ML-DSA-87 + Ed448 combination.
Consider signing with two signatures: traditional and composite.
The traditional signature would use whatever algorithm is used today.
Legacy verifiers would only check that.
The composite signature would use:
ML-DSA-87 + Ed448 (+ SHAKE256 if using the CMS composite construction)
New verifiers would only check the composite signature (which requires
checking both of its parts).
That composite would be
* FIPS compliant (all the algorithms are)
* CNSA compliant (ML-DSA-87 makes it so; the rest is just noise)
* compliant with any European requirements or preferences for using hybrids
* compliant with any requirements or preferences for high security strengths
* even with two algorithms, faster than the traditional choices for signing,
and faster than ECDSA but slower than RSASSA for verification. By bringing
in Ed448, it might be viewed as an improvement even by PQC skeptics.
It'd be nice if signed kernel modules and packages used the same
algorithms. Both of these define ML-DSA-87 + Ed448 composites:
* draft-ietf-lamps-pq-composite-sigs
* id-MLDSA87-Ed448-SHAKE256 with OID: 1.3.6.1.5.5.7.6.51
* draft-ietf-openpgp-pqc
* ML-DSA-87+Ed448 as public key algorithm ID 31
^ permalink raw reply
* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Mimi Zohar @ 2025-11-07 19:28 UTC (permalink / raw)
To: Coiby Xu
Cc: Paul Moore, linux-integrity, linux-security-module, Karel Srot,
James Morris, Serge E. Hallyn, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, open list, open list:MODULE SUPPORT
In-Reply-To: <b9eb78105115a00731b3677a5f3a39d5dde4d2ec.camel@linux.ibm.com>
On Thu, 2025-11-06 at 17:15 -0500, Mimi Zohar wrote:
> On Thu, 2025-11-06 at 21:29 +0800, Coiby Xu wrote:
> > On Wed, Nov 05, 2025 at 03:47:25PM -0500, Mimi Zohar wrote:
> > > On Wed, 2025-11-05 at 08:18 +0800, Coiby Xu wrote:
> > [...]
> > >
> > > Hi Coiby,
> > >
> > > Based on the conversation with Paul, there is no reason to remove the existing
> > > security_kernel_post_read_file() call.
> > >
> > > The changes are similar to the 2nd link, but a bit different.
> > > - Define a single enumeration named READING_MODULE_COMPRESSED.
> > >
> > > - In module/main.c add a new security_kernel_post_read_file() call immediately
> > > after decompressing the kernel module. Like a previous version of this patch,
> > > call kernel_read_file() with either READING_MODULE or READING_MODULE_COMPRESSED
> > > based on MODULE_INIT_COMPRESSED_FILE.
> > >
> > > - In ima_post_read_file() defer verifying the signature when the enumeration is
> > > READING_MODULE_COMPRESSED. (No need for a new function ima_read_kernel_module.)
> >
> > Hi Mimi,
> >
> > Thanks for summarizing your conversation with Paul! I can confirm Paul's
> > approach works
> > https://github.com/coiby/linux/tree/in_kernel_decompression_ima_no_lsm_hook_paul
> >
> > While testing the patch today, I realized there is another
> > issue/challenge introduced by in-kernel module decompression. IMA
> > appraisal is to verify the digest of compressed kernel module but
> > currently the passed buffer is uncompressed module. When IMA uses
> > uncompressed module data to calculate the digest, xattr signature
> > verification will fail. If we always make IMA read the original kernel
> > module data again to calculate the digest, does it look like a
> > quick-and-dirty fix? If we can assume people won't load kernel module so
> > often, the performance impact is negligible. Otherwise we may have to
> > introduce a new LSM hook so IMA can access uncompressed and original
> > module data one time.
>
> ima_collect_measurement() stores the file hash info in the iint and uses that
> information to verify the signature as stored in the security xattr.
> Decompressing the kernel module shouldn't affect the xattr signature
> verification.
In the case when the compressed kernel module hasn't previously been measured or
appraised before loading the kernel module, we need to "collect" the file data
hash on READING_MODULE_COMPRESSED, but defer appraising/measuring it.
An alternative to your suggestion of re-reading the original kernel module data
to calculate the digest or defining a new hook, would be to define "collect" as
a new "action" and pass the kernel_read_file_id enumeration to
process_measurement(). IMA_COLLECTED already exists. Only IMA_COLLECT would
need to be defined. The new collect "action" should be limited to
func=MODULE_CHECK.
The downside of this alternative is that it requires a new collect rule:
collect func=MODULE_CHECK mask=MAY_READ uid=0
appraise func=MODULE_CHECK appraise_type=imasig|modsig
--
thanks,
Mimi
^ permalink raw reply
* Re: Module signing and post-quantum crypto public key algorithms
From: Stefan Berger @ 2025-11-07 19:19 UTC (permalink / raw)
To: David Howells
Cc: Simo Sorce, James Bottomley, Ignat Korchagin, Herbert Xu,
Stephan Mueller, torvalds, Paul Moore, Lukas Wunner, Clemens Lang,
David Bohannon, Roberto Sassu, keyrings, linux-crypto,
linux-security-module, linux-kernel
In-Reply-To: <61528.1762509829@warthog.procyon.org.uk>
On 11/7/25 5:03 AM, David Howells wrote:
> Stefan Berger <stefanb@linux.ibm.com> wrote:
>
>> On 6/16/25 1:27 PM, Simo Sorce wrote:
>>> Of course we can decide to hedge *all bets* and move to a composed
>>> signature (both a classic and a PQ one), in which case I would suggest
>>> looking into signatures that use ML-DSA-87 + Ed448 or ML-DSA-87 + P-521
>>> ,ideally disjoint, with a kernel policy that can decide which (or both)
>>> needs to be valid/checked so that the policy can be changed quickly via
>>> configuration if any of the signature is broken.
>>
>> FYI: based on this implementation of ML-DSA-44/65/87
>>
>> https://github.com/IBM/mlca/tree/main/qsc/crystals
>
> The problem with that is that the Apache-2 licence is incompatible with GPLv2.
> Now, it might be possible to persuade IBM to dual-license their code.
Correct. It was supposed to become GPLv2 + Apache 2.
>
> David
>
>
^ permalink raw reply
* [syzbot] [lsm?] WARNING in put_cred_rcu
From: syzbot @ 2025-11-07 14:05 UTC (permalink / raw)
To: linux-kernel, linux-security-module, luto, peterz, syzkaller-bugs,
tglx
Hello,
syzbot found the following issue on:
HEAD commit: 17490bd0527f Add linux-next specific files for 20251104
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16c09bcd980000
kernel config: https://syzkaller.appspot.com/x/.config?x=9995c0d2611ab121
dashboard link: https://syzkaller.appspot.com/bug?extid=553c4078ab14e3cf3358
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1500a532580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e0a114580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/a4d318147846/disk-17490bd0.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/86641a470170/vmlinux-17490bd0.xz
kernel image: https://storage.googleapis.com/syzbot-assets/35c008a540c8/bzImage-17490bd0.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+553c4078ab14e3cf3358@syzkaller.appspotmail.com
------------[ cut here ]------------
WARNING: ./include/linux/ns_common.h:255 at __ns_ref_put include/linux/ns_common.h:255 [inline], CPU#0: syz.1.27/6120
WARNING: ./include/linux/ns_common.h:255 at put_user_ns include/linux/user_namespace.h:189 [inline], CPU#0: syz.1.27/6120
WARNING: ./include/linux/ns_common.h:255 at put_cred_rcu+0x2c5/0x340 kernel/cred.c:61, CPU#0: syz.1.27/6120
Modules linked in:
CPU: 0 UID: 0 PID: 6120 Comm: syz.1.27 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
RIP: 0010:__ns_ref_put include/linux/ns_common.h:255 [inline]
RIP: 0010:put_user_ns include/linux/user_namespace.h:189 [inline]
RIP: 0010:put_cred_rcu+0x2c5/0x340 kernel/cred.c:61
Code: 5c 41 5d 41 5e 41 5f 5d e9 b8 41 8d 00 e8 03 77 32 00 4c 89 e7 be 03 00 00 00 e8 d6 19 07 03 e9 b8 fe ff ff e8 ec 76 32 00 90 <0f> 0b 90 eb 9f e8 e1 76 32 00 4c 89 ff be 03 00 00 00 e8 b4 19 07
RSP: 0018:ffffc90000007ba8 EFLAGS: 00010246
RAX: ffffffff818ee5a4 RBX: ffff88801c3762a0 RCX: ffff888027350000
RDX: 0000000000000100 RSI: 0000000000000004 RDI: 0000000000000000
RBP: 0000000000000004 R08: ffff888073d31eab R09: 1ffff1100e7a63d5
R10: dffffc0000000000 R11: ffffed100e7a63d6 R12: dffffc0000000000
R13: ffff88801c376200 R14: ffff888073d31d18 R15: ffff888073d31ea8
FS: 00007fcce9f9d6c0(0000) GS:ffff888125a92000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555684fe808 CR3: 000000007ee2c000 CR4: 00000000003526f0
Call Trace:
<IRQ>
rcu_do_batch kernel/rcu/tree.c:2605 [inline]
rcu_core+0xcab/0x1770 kernel/rcu/tree.c:2861
handle_softirqs+0x286/0x870 kernel/softirq.c:626
__do_softirq kernel/softirq.c:660 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:727
irq_exit_rcu+0x9/0x30 kernel/softirq.c:743
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:lock_acquire+0x175/0x360 kernel/locking/lockdep.c:5872
Code: 00 00 00 00 9c 8f 44 24 30 f7 44 24 30 00 02 00 00 0f 85 cd 00 00 00 f7 44 24 08 00 02 00 00 74 01 fb 65 48 8b 05 bb 94 1a 11 <48> 3b 44 24 58 0f 85 f2 00 00 00 48 83 c4 60 5b 41 5c 41 5d 41 5e
RSP: 0018:ffffc90002ec5f58 EFLAGS: 00000206
RAX: c3b7b02cbda44300 RBX: 0000000000000000 RCX: c3b7b02cbda44300
RDX: 0000000000000000 RSI: ffffffff8dc69c71 RDI: ffffffff8be0fc60
RBP: ffffffff817420d5 R08: 0000000000000000 R09: ffffffff817420d5
R10: ffffc90002ec6118 R11: ffffffff81ad6a10 R12: 0000000000000002
R13: ffffffff8e33b520 R14: 0000000000000000 R15: 0000000000000246
rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
rcu_read_lock include/linux/rcupdate.h:867 [inline]
class_rcu_constructor include/linux/rcupdate.h:1195 [inline]
unwind_next_frame+0xc2/0x2390 arch/x86/kernel/unwind_orc.c:479
arch_stack_walk+0x11c/0x150 arch/x86/kernel/stacktrace.c:25
stack_trace_save+0x9c/0xe0 kernel/stacktrace.c:122
save_stack+0xf5/0x1f0 mm/page_owner.c:165
__set_page_owner+0x8d/0x4c0 mm/page_owner.c:341
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851
prep_new_page mm/page_alloc.c:1859 [inline]
get_page_from_freelist+0x2365/0x2440 mm/page_alloc.c:3920
__alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5214
alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2479
folio_alloc_mpol_noprof+0x39/0x70 mm/mempolicy.c:2498
shmem_alloc_folio mm/shmem.c:1900 [inline]
shmem_alloc_and_add_folio+0x423/0xf40 mm/shmem.c:1942
shmem_get_folio_gfp+0x59d/0x1660 mm/shmem.c:2565
shmem_get_folio mm/shmem.c:2671 [inline]
shmem_write_begin+0xf7/0x2b0 mm/shmem.c:3320
generic_perform_write+0x2c5/0x900 mm/filemap.c:4313
shmem_file_write_iter+0xf8/0x120 mm/shmem.c:3495
__kernel_write_iter+0x428/0x910 fs/read_write.c:619
dump_emit_page fs/coredump.c:1298 [inline]
dump_user_range+0x8a0/0xc90 fs/coredump.c:1372
elf_core_dump+0x3369/0x3960 fs/binfmt_elf.c:2111
coredump_write+0x116c/0x1900 fs/coredump.c:1049
vfs_coredump+0x1db5/0x2a60 fs/coredump.c:1170
get_signal+0x1108/0x1340 kernel/signal.c:3019
arch_do_signal_or_restart+0xa0/0x790 arch/x86/kernel/signal.c:337
exit_to_user_mode_loop kernel/entry/common.c:40 [inline]
exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
irqentry_exit_to_user_mode+0x7e/0x170 kernel/entry/common.c:73
exc_page_fault+0xab/0x100 arch/x86/mm/fault.c:1535
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
RIP: 0033:0x7fcce918f6d1
Code: 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 48 3d 01 f0 ff ff 73 01 <c3> 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f
RSP: 002b:0000000000000010 EFLAGS: 00010217
RAX: 0000000000000000 RBX: 00007fcce93e5fa0 RCX: 00007fcce918f6c9
RDX: 0000000000000000 RSI: 0000000000000010 RDI: 498144ee5f62e049
RBP: 00007fcce9211f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
R13: 00007fcce93e6038 R14: 00007fcce93e5fa0 R15: 00007ffd4dc9bfc8
</TASK>
----------------
Code disassembly (best guess):
0: 00 00 add %al,(%rax)
2: 00 00 add %al,(%rax)
4: 9c pushf
5: 8f 44 24 30 pop 0x30(%rsp)
9: f7 44 24 30 00 02 00 testl $0x200,0x30(%rsp)
10: 00
11: 0f 85 cd 00 00 00 jne 0xe4
17: f7 44 24 08 00 02 00 testl $0x200,0x8(%rsp)
1e: 00
1f: 74 01 je 0x22
21: fb sti
22: 65 48 8b 05 bb 94 1a mov %gs:0x111a94bb(%rip),%rax # 0x111a94e5
29: 11
* 2a: 48 3b 44 24 58 cmp 0x58(%rsp),%rax <-- trapping instruction
2f: 0f 85 f2 00 00 00 jne 0x127
35: 48 83 c4 60 add $0x60,%rsp
39: 5b pop %rbx
3a: 41 5c pop %r12
3c: 41 5d pop %r13
3e: 41 5e pop %r14
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [Patch V1] ima: avoid duplicate policy rules insertions
From: Roberto Sassu @ 2025-11-07 11:56 UTC (permalink / raw)
To: Lennart Poettering
Cc: Tahera Fahimi, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge, linux-integrity,
linux-security-module, linux-kernel, code
In-Reply-To: <aQ3QV03_PtB4qg32@gardel-login>
On Fri, 2025-11-07 at 11:56 +0100, Lennart Poettering wrote:
> On Fr, 07.11.25 10:44, Roberto Sassu (roberto.sassu@huaweicloud.com) wrote:
>
> > On Thu, 2025-11-06 at 18:14 +0000, Tahera Fahimi wrote:
> > > Prevent redundant IMA policy rules by checking for duplicates before insertion. This ensures that
> > > rules are not re-added when userspace is restarted (using systemd-soft-reboot) without a full system
> > > reboot. ima_rule_exists() detects duplicates in both temporary and active rule lists.
> >
> > + Lennart
> >
> > Hi Tahera
> >
> > thanks for the patch!
> >
> > Wouldn't be better to enhance systemd-soft-reboot to not send the same
> > IMA policy again?
>
> the soft-reboot logic doesn't load the IMA policy. It's just that
> soft-reboot means we reexec PID1: the old pid1 gets replaced by the
> new one. And that new PID1 then initializes as it usually would, and
> loads security policies again. It currently has support for selinux
> policies, ima, ipe, smack.
>
> These policies are supposed to *replace* whatever was loaded
> before. Looking at our IMA logic, this doesn't happen right now
> though, it just adds stuff:
From a functional perspective. As far as integrity is concerned, you
would probably agree that just replacing PID 1 does not mean resetting
the integrity of the system to a known state (all the other processes
are still running). Due to that, I think the concept of soft-reset
should not be applied to the kernel.
> https://github.com/systemd/systemd/blob/main/src/core/ima-setup.c
>
> Is there a way to replace the old IMA policy with the new, with the
> current IMA userspace interface? If so, we should probably make use of
No, only the IMA boot policies specified in the kernel command line can
be reset (only once, and not completely, secure boot rules still
persist despite user space loads a new policy). New rules are append-
only.
> that in systemd, and replace the policy that way. Or in other words:
> under the assumption that one can flush out the old IMA policy and
> replace it with a new one, I think this should be fixed in systemd,
> not the kernel. (of there's no api for flushing out the old
> policy/replacing it with the new, then of course we need something
> like that in the kernel first).
Assuming that technically it is feasible to flush the old IMA policy
(except for the permanent secure boot rules). What it would be the
additional value of changing the policy on the fly on the same system
as before, but with a different PID 1?
Regarding the duplicate IMA policy load, I guess you could probably
store the digest of the currently loaded policy in the systemd state
and not doing it again after soft-reboot, if the digest matches.
Roberto
> My understanding of IMA is kinda limited though. I just know what we
> do in our codebase.
>
> Lennart
^ permalink raw reply
* Re: [Patch V1] ima: avoid duplicate policy rules insertions
From: Lennart Poettering @ 2025-11-07 10:56 UTC (permalink / raw)
To: Roberto Sassu
Cc: Tahera Fahimi, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge, linux-integrity,
linux-security-module, linux-kernel, code
In-Reply-To: <1cc67c25a141aef8982840898a6e7397cbdf10d9.camel@huaweicloud.com>
On Fr, 07.11.25 10:44, Roberto Sassu (roberto.sassu@huaweicloud.com) wrote:
> On Thu, 2025-11-06 at 18:14 +0000, Tahera Fahimi wrote:
> > Prevent redundant IMA policy rules by checking for duplicates before insertion. This ensures that
> > rules are not re-added when userspace is restarted (using systemd-soft-reboot) without a full system
> > reboot. ima_rule_exists() detects duplicates in both temporary and active rule lists.
>
> + Lennart
>
> Hi Tahera
>
> thanks for the patch!
>
> Wouldn't be better to enhance systemd-soft-reboot to not send the same
> IMA policy again?
the soft-reboot logic doesn't load the IMA policy. It's just that
soft-reboot means we reexec PID1: the old pid1 gets replaced by the
new one. And that new PID1 then initializes as it usually would, and
loads security policies again. It currently has support for selinux
policies, ima, ipe, smack.
These policies are supposed to *replace* whatever was loaded
before. Looking at our IMA logic, this doesn't happen right now
though, it just adds stuff:
https://github.com/systemd/systemd/blob/main/src/core/ima-setup.c
Is there a way to replace the old IMA policy with the new, with the
current IMA userspace interface? If so, we should probably make use of
that in systemd, and replace the policy that way. Or in other words:
under the assumption that one can flush out the old IMA policy and
replace it with a new one, I think this should be fixed in systemd,
not the kernel. (of there's no api for flushing out the old
policy/replacing it with the new, then of course we need something
like that in the kernel first).
My understanding of IMA is kinda limited though. I just know what we
do in our codebase.
Lennart
^ permalink raw reply
* Re: Module signing and post-quantum crypto public key algorithms
From: Stephan Mueller @ 2025-11-07 10:23 UTC (permalink / raw)
To: Stefan Berger, David Howells
Cc: dhowells, Simo Sorce, James Bottomley, Ignat Korchagin,
Herbert Xu, torvalds, Paul Moore, Lukas Wunner, Clemens Lang,
David Bohannon, Roberto Sassu, keyrings, linux-crypto,
linux-security-module, linux-kernel
In-Reply-To: <61528.1762509829@warthog.procyon.org.uk>
Am Freitag, 7. November 2025, 11:03:49 Mitteleuropäische Normalzeit schrieb
David Howells:
Hi David,
> Stefan Berger <stefanb@linux.ibm.com> wrote:
> > On 6/16/25 1:27 PM, Simo Sorce wrote:
> > > Of course we can decide to hedge *all bets* and move to a composed
> > > signature (both a classic and a PQ one), in which case I would suggest
> > > looking into signatures that use ML-DSA-87 + Ed448 or ML-DSA-87 + P-521
> > > ,ideally disjoint, with a kernel policy that can decide which (or both)
> > > needs to be valid/checked so that the policy can be changed quickly via
> > > configuration if any of the signature is broken.
> >
> > FYI: based on this implementation of ML-DSA-44/65/87
> >
> > https://github.com/IBM/mlca/tree/main/qsc/crystals
>
> The problem with that is that the Apache-2 licence is incompatible with
> GPLv2. Now, it might be possible to persuade IBM to dual-license their
> code.
The code used as a basis for the current approach (leancrypto.org) offers
hybrids with ED25519 and ED448) including the X.509/PKCS7 support.
However, please note that the X.509 specification for storing hybrid public
keys is not yet completed and there is still some work on the draft IETF
standard [1].
Side note: the leancrypto code base uses the Linux kernel X.509/PKCS7 parser
code where the relevant handler functions (see [2]) could be relatively
quickly transplanted into the kernel if needed.
[1] https://lamps-wg.github.io/draft-composite-sigs/draft-ietf-lamps-pq-composite-sigs.html
[2] https://github.com/smuellerDD/leancrypto/blob/master/asn1/src/
x509_cert_parser.c
Ciao
Stephan
^ permalink raw reply
* Re: Module signing and post-quantum crypto public key algorithms
From: David Howells @ 2025-11-07 10:03 UTC (permalink / raw)
To: Stefan Berger
Cc: dhowells, Simo Sorce, James Bottomley, Ignat Korchagin,
Herbert Xu, Stephan Mueller, torvalds, Paul Moore, Lukas Wunner,
Clemens Lang, David Bohannon, Roberto Sassu, keyrings,
linux-crypto, linux-security-module, linux-kernel
In-Reply-To: <53e81761-47e1-400e-933d-0a53018c9cab@linux.ibm.com>
Stefan Berger <stefanb@linux.ibm.com> wrote:
> On 6/16/25 1:27 PM, Simo Sorce wrote:
> > Of course we can decide to hedge *all bets* and move to a composed
> > signature (both a classic and a PQ one), in which case I would suggest
> > looking into signatures that use ML-DSA-87 + Ed448 or ML-DSA-87 + P-521
> > ,ideally disjoint, with a kernel policy that can decide which (or both)
> > needs to be valid/checked so that the policy can be changed quickly via
> > configuration if any of the signature is broken.
>
> FYI: based on this implementation of ML-DSA-44/65/87
>
> https://github.com/IBM/mlca/tree/main/qsc/crystals
The problem with that is that the Apache-2 licence is incompatible with GPLv2.
Now, it might be possible to persuade IBM to dual-license their code.
David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox