* Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()
From: Tetsuo Handa @ 2026-01-27 3:51 UTC (permalink / raw)
To: Paul Moore, SELinux, linux-security-module
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Network Development
In-Reply-To: <CAHC9VhQikhv+qCyQdnJguvy-qTkGXB+NU7=QZjw5d+WfyVxZhw@mail.gmail.com>
On 2026/01/27 7:33, Paul Moore wrote:
> On Fri, Jan 23, 2026 at 5:13 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>
>> Since xfrm_dev_{state,policy}_flush() are called from only NETDEV_DOWN and
>> NETDEV_UNREGISTER events, making xfrm_dev_{state,policy}_flush() no-op by
>> returning an error value from xfrm_dev_{state,policy}_flush_secctx_check()
>> is pointless. Especially, if xfrm_dev_{state,policy}_flush_secctx_check()
>> returned an error value upon NETDEV_UNREGISTER event, the system will hung
>> up with
>>
>> unregister_netdevice: waiting for $dev to become free. Usage count = $count
>>
>> message because the reference to $dev acquired by
>> xfrm_dev_{state,policy}_add() cannot be released.
>>
>> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>> ---
>> net/xfrm/xfrm_policy.c | 35 -----------------------------------
>> net/xfrm/xfrm_state.c | 33 ---------------------------------
>> 2 files changed, 68 deletions(-)
>
> I didn't make it very far into reviewing this patch, because it looks
> like xfrm_dev_state_flush() is called by the bonding driver's
> notification handler, and I don't see that reflected in this patch?
xfrm_dev_{state,policy}_flush() are called from only the bonding driver's NETDEV_UNREGISTER
event notification handler and the xfrm module's NETDEV_DOWN event / NETDEV_UNREGISTER event
notification handler ( https://elixir.bootlin.com/linux/v6.19-rc5/A/ident/xfrm_dev_state_flush ).
What this patch kills is not xfrm_dev_{state,policy}_flush() but
xfrm_dev_{state,policy}_flush_secctx_check(). No need to touch the bonding driver.
LSM hook for checking whether to allow deleting a file in tmpfs which is still mounted
makes sense, LSM hook for checking whether to allow starting unmount of tmpfs makes sense,
but LSM hook for checking whether to allow releasing memory in tmpfs while unmount operation
is already in progress causes nothing but a resource leak / denial-of-service kernel bug.
What xfrm_dev_{state,policy}_flush_secctx_check() are causing is something like
"LSM policy is refusing release of memory used by a file in tmpfs which is already under
unmount operation".
xfrm_dev_{state,policy}_flush_secctx_check() are too late to make LSM policy decision.
A must-not-fail operation has already started before LSM hooks are called.
^ permalink raw reply
* [PATCH] ima_fs: Avoid creating measurement lists for unsupported hash algos
From: Dmitry Safonov via B4 Relay @ 2026-01-27 3:05 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi
Cc: linux-integrity, linux-security-module, linux-kernel,
Dmitry Safonov, Dmitry Safonov
From: Dmitry Safonov <dima@arista.com>
ima_init_crypto() skips initializing ima_algo_array[i] if the alogorithm
from ima_tpm_chip->allocated_banks[i].crypto_id is not supported.
It seems avoid adding the unsupported algorithm to ima_algo_array will
break all the logic that relies on indexing by NR_BANKS(ima_tpm_chip).
Grepping HASH_ALGO__LAST in security/integrity/ima/ shows that is
the check other logic relies on, so make
create_securityfs_measurement_lists() ignore unknown algorithms.
On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
> ==================================================================
> BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
> Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
>
> CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
> Call Trace:
> <TASK>
> dump_stack_lvl+0x61/0x90
> print_report+0xc4/0x580
> ? kasan_addr_to_slab+0x26/0x80
> ? create_securityfs_measurement_lists+0x396/0x440
> kasan_report+0xc2/0x100
> ? create_securityfs_measurement_lists+0x396/0x440
> create_securityfs_measurement_lists+0x396/0x440
> ima_fs_init+0xa3/0x300
> ima_init+0x7d/0xd0
> init_ima+0x28/0x100
> do_one_initcall+0xa6/0x3e0
> kernel_init_freeable+0x455/0x740
> kernel_init+0x24/0x1d0
> ret_from_fork+0x38/0x80
> ret_from_fork_asm+0x11/0x20
> </TASK>
>
> The buggy address belongs to the variable:
> hash_algo_name+0xb8/0x420
>
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x107ce18
> flags: 0x8000000000002000(reserved|zone=2)
> raw: 8000000000002000 ffffea0041f38608 ffffea0041f38608 0000000000000000
> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
> ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
> ^
> ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
> ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
> ==================================================================
Seems like the TPM chip supports sha3_256, which isn't yet in
tpm_algorithms:
> tpm tpm0: TPM with unsupported bank algorithm 0x0027
Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm")
Signed-off-by: Dmitry Safonov <dima@arista.com>
Cc: Enrico Bravi <enrico.bravi@polito.it>
Cc: Silvia Sisinni <silvia.sisinni@polito.it>
Cc: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
---
security/integrity/ima/ima_fs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index 012a58959ff0..e9283229acea 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -404,6 +404,9 @@ static int __init create_securityfs_measurement_lists(void)
char file_name[NAME_MAX + 1];
struct dentry *dentry;
+ if (algo == HASH_ALGO__LAST)
+ continue;
+
sprintf(file_name, "ascii_runtime_measurements_%s",
hash_algo_name[algo]);
dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260127-ima-oob-9fa83a634d7b
Best regards,
--
Dmitry Safonov <dima@arista.com>
^ permalink raw reply related
* Re: [PATCH] ipc: don't audit capability check in ipc_permissions()
From: Serge E. Hallyn @ 2026-01-27 2:01 UTC (permalink / raw)
To: Paul Moore
Cc: Ondrej Mosnacek, Serge Hallyn, Andrew Morton, Eric W . Biederman,
Alexey Gladkov, linux-kernel, linux-security-module, selinux
In-Reply-To: <CAHC9VhQYLJVweDgBkRo=0_kS1TAUQH_YfT+woSfBW0SjUO4nqg@mail.gmail.com>
On Mon, Jan 26, 2026 at 05:50:12PM -0500, Paul Moore wrote:
> On Thu, Jan 22, 2026 at 9:56 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > The IPC sysctls implement the ctl_table_root::permissions hook and
> > they override the file access mode based on the CAP_CHECKPOINT_RESTORE
> > capability, which is being checked regardless of whether any access is
> > actually denied or not, so if an LSM denies the capability, an audit
> > record may be logged even when access is in fact granted.
> >
> > It wouldn't be viable to restructure the sysctl permission logic to only
> > check the capability when the access would be actually denied if it's
> > not granted. Thus, do the same as in net_ctl_permissions()
> > (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(),
> > so that the check never emits an audit record.
> >
> > Fixes: 0889f44e2810 ("ipc: Check permissions for checkpoint_restart sysctls at open time")
> > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> > ---
> > include/linux/capability.h | 6 ++++++
> > ipc/ipc_sysctl.c | 2 +-
> > 2 files changed, 7 insertions(+), 1 deletion(-)
>
> This change seems reasonable to me, but I would make sure Serge has a
> chance to review/ACK this patch as it has a capability impact.
Acked-by: Serge Hallyn <serge@hallyn.com>
Thanks - looks good to me.
^ permalink raw reply
* Re: [PATCH] ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit()
From: Serge E. Hallyn @ 2026-01-27 1:47 UTC (permalink / raw)
To: Paul Moore
Cc: Ondrej Mosnacek, Andrew Morton, Eric W . Biederman, linux-kernel,
linux-security-module, selinux
In-Reply-To: <CAHC9VhSgbHx4NcMVjMMk0D332b0DTEQi6dD_wO1fvQne-JVisw@mail.gmail.com>
On Mon, Jan 26, 2026 at 05:52:03PM -0500, Paul Moore wrote:
> On Thu, Jan 22, 2026 at 9:25 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > The user.* sysctls implement the ctl_table_root::permissions hook and
> > they override the file access mode based on the CAP_SYS_RESOURCE
> > capability (at most rwx if capable, at most r-- if not). The capability
> > is being checked unconditionally, so if an LSM denies the capability, an
> > audit record may be logged even when access is in fact granted.
> >
> > Given the logic in the set_permissions() function in kernel/ucount.c and
> > the unfortunate way the permission checking is implemented, it doesn't
> > seem viable to avoid false positive denials by deferring the capability
> > check. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c)
> > - switch from ns_capable() to ns_capable_noaudit(), so that the check
> > never logs an audit record.
> >
> > Fixes: dbec28460a89 ("userns: Add per user namespace sysctls.")
> > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> > ---
> > kernel/ucount.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Paul Moore <paul@paul-moore.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
Looks good to me. What tree should this go through? Network?
^ permalink raw reply
* Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
From: Marco Elver @ 2026-01-26 23:46 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Bart Van Assche, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <20260126213556.GQ171111@noisy.programming.kicks-ass.net>
On Mon, 26 Jan 2026 at 22:36, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Jan 26, 2026 at 10:54:56AM -0800, Bart Van Assche wrote:
>
> > Has it ever been considered to add support in the clang compiler for a
> > variant of __must_hold() that expresses that one of two capabilities
> > must be held by the caller? I think that would remove the need to
> > annotate SRCU update-side code with __acquire_shared(ssp) and
> > __release_shared(ssp).
>
> Right, I think I've asked for logical operators like that. Although I
> think it was in the __guarded_by() clause rather than the __must_hold().
> Both || and && would be nice to have ;-)
Some attributes take multiple arguments (__must_hold does), though
__guarded_by doesn't. Yet, && can still be had with adding it multiple
times e.g. '__guarded_by(pi_lock) __guarded_by(rq->__lock)'.
Only thing that doesn't exist is ||. I think the syntax you ask for
won't fly, but I can add it to the backlog to investigate an _any
variant of these attributes. Don't hold your breath though, given the
time it takes to land all that in a released Clang version.
> Specifically, I think I asked for something like:
>
> cpumask_t cpus_allowed __guarded_by(pi_lock && rq->__lock)
> __guarded_shared_by(pi_lock || rq->__lock);
>
>
> I think Marco's suggestion was to use 'fake' locks to mimic those
> semantics.
^ permalink raw reply
* Re: [PATCH] ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit()
From: Paul Moore @ 2026-01-26 22:52 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: Andrew Morton, Eric W . Biederman, linux-kernel,
linux-security-module, selinux
In-Reply-To: <20260122140745.239428-1-omosnace@redhat.com>
On Thu, Jan 22, 2026 at 9:25 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> The user.* sysctls implement the ctl_table_root::permissions hook and
> they override the file access mode based on the CAP_SYS_RESOURCE
> capability (at most rwx if capable, at most r-- if not). The capability
> is being checked unconditionally, so if an LSM denies the capability, an
> audit record may be logged even when access is in fact granted.
>
> Given the logic in the set_permissions() function in kernel/ucount.c and
> the unfortunate way the permission checking is implemented, it doesn't
> seem viable to avoid false positive denials by deferring the capability
> check. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c)
> - switch from ns_capable() to ns_capable_noaudit(), so that the check
> never logs an audit record.
>
> Fixes: dbec28460a89 ("userns: Add per user namespace sysctls.")
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> ---
> kernel/ucount.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Paul Moore <paul@paul-moore.com>
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] ipc: don't audit capability check in ipc_permissions()
From: Paul Moore @ 2026-01-26 22:50 UTC (permalink / raw)
To: Ondrej Mosnacek, Serge Hallyn
Cc: Andrew Morton, Eric W . Biederman, Alexey Gladkov, linux-kernel,
linux-security-module, selinux
In-Reply-To: <20260122141303.241133-1-omosnace@redhat.com>
On Thu, Jan 22, 2026 at 9:56 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> The IPC sysctls implement the ctl_table_root::permissions hook and
> they override the file access mode based on the CAP_CHECKPOINT_RESTORE
> capability, which is being checked regardless of whether any access is
> actually denied or not, so if an LSM denies the capability, an audit
> record may be logged even when access is in fact granted.
>
> It wouldn't be viable to restructure the sysctl permission logic to only
> check the capability when the access would be actually denied if it's
> not granted. Thus, do the same as in net_ctl_permissions()
> (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(),
> so that the check never emits an audit record.
>
> Fixes: 0889f44e2810 ("ipc: Check permissions for checkpoint_restart sysctls at open time")
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> ---
> include/linux/capability.h | 6 ++++++
> ipc/ipc_sysctl.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
This change seems reasonable to me, but I would make sure Serge has a
chance to review/ACK this patch as it has a capability impact.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] xfrm: force flush upon NETDEV_UNREGISTER event
From: Paul Moore @ 2026-01-26 22:41 UTC (permalink / raw)
To: Steffen Klassert
Cc: Tetsuo Handa, Aviad Yehezkel, Aviv Heller, Boris Pismenny,
David S. Miller, Florian Westphal, Guy Shapiro, Ilan Tayari,
Kristian Evensen, Leon Romanovsky, Leon Romanovsky, Raed Salem,
Raed Salem, Saeed Mahameed, Yossi Kuperman, Network Development,
linux-security-module
In-Reply-To: <aXIGxmCB2QU86-iA@secunet.com>
On Thu, Jan 22, 2026 at 7:00 AM Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> On Thu, Jan 22, 2026 at 05:24:22PM +0900, Tetsuo Handa wrote:
...
> > Therefore, I wonder what are security_xfrm_state_delete() and security_xfrm_policy_delete()
> > for. Can I kill xfrm_dev_state_flush_secctx_check() and xfrm_dev_policy_flush_secctx_check() ?
>
> This might violate a LSM policy then.
Exactly. SELinux is currently the only LSM that enforces any access
controls on the XFRM/IPsec code, but it does use both of these LSM
hooks to authorize deletion of SPD/SA objects.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()
From: Paul Moore @ 2026-01-26 22:33 UTC (permalink / raw)
To: Tetsuo Handa
Cc: linux-security-module, SELinux, Steffen Klassert, Herbert Xu,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Network Development
In-Reply-To: <2ec9c137-79a5-4562-8587-43dd2633f116@I-love.SAKURA.ne.jp>
On Fri, Jan 23, 2026 at 5:13 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> Since xfrm_dev_{state,policy}_flush() are called from only NETDEV_DOWN and
> NETDEV_UNREGISTER events, making xfrm_dev_{state,policy}_flush() no-op by
> returning an error value from xfrm_dev_{state,policy}_flush_secctx_check()
> is pointless. Especially, if xfrm_dev_{state,policy}_flush_secctx_check()
> returned an error value upon NETDEV_UNREGISTER event, the system will hung
> up with
>
> unregister_netdevice: waiting for $dev to become free. Usage count = $count
>
> message because the reference to $dev acquired by
> xfrm_dev_{state,policy}_add() cannot be released.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> net/xfrm/xfrm_policy.c | 35 -----------------------------------
> net/xfrm/xfrm_state.c | 33 ---------------------------------
> 2 files changed, 68 deletions(-)
I didn't make it very far into reviewing this patch, because it looks
like xfrm_dev_state_flush() is called by the bonding driver's
notification handler, and I don't see that reflected in this patch?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
From: Peter Zijlstra @ 2026-01-26 21:35 UTC (permalink / raw)
To: Bart Van Assche
Cc: Marco Elver, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <8c1bbab4-4615-4518-b773-a006d1402b8b@acm.org>
On Mon, Jan 26, 2026 at 10:54:56AM -0800, Bart Van Assche wrote:
> Has it ever been considered to add support in the clang compiler for a
> variant of __must_hold() that expresses that one of two capabilities
> must be held by the caller? I think that would remove the need to
> annotate SRCU update-side code with __acquire_shared(ssp) and
> __release_shared(ssp).
Right, I think I've asked for logical operators like that. Although I
think it was in the __guarded_by() clause rather than the __must_hold().
Both || and && would be nice to have ;-)
Specifically, I think I asked for something like:
cpumask_t cpus_allowed __guarded_by(pi_lock && rq->__lock)
__guarded_shared_by(pi_lock || rq->__lock);
I think Marco's suggestion was to use 'fake' locks to mimic those
semantics.
^ permalink raw reply
* [ANN] Linux Security Summit 2026 CfP
From: James Morris @ 2026-01-26 20:58 UTC (permalink / raw)
To: linux-security-module
Cc: Linux Security Summit Program Committee, linux-kernel,
kernel-hardening, linux-integrity, lwn, linux-crypto, keyrings
=============================================================================
ANNOUNCEMENT AND CALL FOR PARTICIPATION
LINUX SECURITY SUMMIT NORTH AMERICA 2026
May 21-22
Minneapolis, MN, USA
==============================================================================
DESCRIPTION
Linux Security Summit North America (LSS-NA) 2026 is a technical forum for
collaboration between Linux developers, researchers, and end-users.
Its primary aim is to foster community efforts in deeply analyzing and
solving Linux operating system security challenges, including those in the
Linux kernel.
Proposals should be submitted via:
https://events.linuxfoundation.org/linux-security-summit-north-america/
SUGGESTED TOPICS
* Access Control
* Case Studies
* Cryptography and Key Management
* Emerging Technologies, Threats & Techniques
* Hardware Security
* IoT and Embedded Security
* Integrity Policy and Enforcement
* Open Source Supply Chain for the Linux OS
* Security Tools
* Security UX
* Linux OS Hardening
* Virtualization and Containers
DATES TO REMEMBER:
* CFP Close: Sunday, March 15 at 11:59 PM CDT
* CFP Notifications: Tuesday, March 31
* Schedule Announced: Thursday, April 2
* Event Date: Thursday, May 21 - Friday, May 22
WHO SHOULD ATTEND
We're seeking a diverse range of attendees and welcome participation by
people involved in Linux security development, operations, and research.
LSS is a unique global event that provides the opportunity to present and
discuss your work or research with key Linux security community members and
maintainers. It's also useful for those who wish to keep up with the latest
in Linux security development and to provide input to the development
process.
MASTODON
For event updates and announcements, follow:
https://social.kernel.org/LinuxSecSummit
#linuxsecuritysummit
PROGRAM COMMITTEE
The program committee for LSS 2026 is:
* James Morris, Microsoft
* Serge Hallyn, Geico
* Paul Moore, Microsoft
* Stephen Smalley, NSA
* Elena Reshetova, Intel
* John Johansen, Canonical
* Kees Cook, Google
* Casey Schaufler
* Mimi Zohar, IBM
* David A. Wheeler, Linux Foundation
The program committee may be contacted as a group via email:
lss-pc () lists.linuxfoundation.org
^ permalink raw reply
* Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
From: Bart Van Assche @ 2026-01-26 18:54 UTC (permalink / raw)
To: Marco Elver
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <aXez9fSxdfu5-Boo@elver.google.com>
On 1/26/26 10:35 AM, Marco Elver wrote:
> That being said, I don't think it's wrong to write e.g.:
>
> spin_lock(&updater_lock);
> __acquire_shared(ssp);
> ...
> // writes happen through rcu_assign_pointer()
> // reads can happen through srcu_dereference_check()
> ...
> __release_shared(ssp);
> spin_unlock(&updater_lock);
>
> , given holding the updater lock implies reader access.
>
> And given the analysis is opt-in (CONTEXT_ANALYSIS := y), I think
> it's a manageable problem.
I'd like to make context-analysis mandatory for the entire kernel tree.
> If you have a different idea how we can solve this, please let us know.
>
> One final note, usage of srcu_dereference_check() is rare enough:
>
> arch/x86/kvm/hyperv.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
> arch/x86/kvm/x86.c: kvm_free_msr_filter(srcu_dereference_check(kvm->arch.msr_filter, &kvm->srcu, 1));
> arch/x86/kvm/x86.c: kfree(srcu_dereference_check(kvm->arch.pmu_event_filter, &kvm->srcu, 1));
> drivers/gpio/gpiolib.c: label = srcu_dereference_check(desc->label, &desc->gdev->desc_srcu,
> drivers/hv/mshv_irq.c: girq_tbl = srcu_dereference_check(partition->pt_girq_tbl,
> drivers/hwtracing/stm/core.c: link = srcu_dereference_check(src->link, &stm_source_srcu, 1);
> drivers/infiniband/hw/hfi1/user_sdma.c: pq = srcu_dereference_check(fd->pq, &fd->pq_srcu,
> fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
> fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
> fs/quota/dquot.c: put[cnt] = srcu_dereference_check(dquots[cnt], &dquot_srcu,
> fs/quota/dquot.c: transfer_from[cnt] = srcu_dereference_check(dquots[cnt],
> include/linux/kvm_host.h: return srcu_dereference_check(kvm->memslots[as_id], &kvm->srcu,
> virt/kvm/irqchip.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
>
> , that I think it's easy enough to annotate these places with the above
> suggestions in case you're trying out global enablement.
Has it ever been considered to add support in the clang compiler for a
variant of __must_hold() that expresses that one of two capabilities
must be held by the caller? I think that would remove the need to
annotate SRCU update-side code with __acquire_shared(ssp) and
__release_shared(ssp).
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
From: Marco Elver @ 2026-01-26 18:35 UTC (permalink / raw)
To: Bart Van Assche
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <dd65bb7b-0dac-437a-a370-38efeb4737ba@acm.org>
On Mon, Jan 26, 2026 at 09:31AM -0800, Bart Van Assche wrote:
> On 12/19/25 7:40 AM, Marco Elver wrote:
> > +/*
> > + * No-op helper to denote that ssp must be held. Because SRCU-protected pointers
> > + * should still be marked with __rcu_guarded, and we do not want to mark them
> > + * with __guarded_by(ssp) as it would complicate annotations for writers, we
> > + * choose the following strategy: srcu_dereference_check() calls this helper
> > + * that checks that the passed ssp is held, and then fake-acquires 'RCU'.
> > + */
> > +static inline void __srcu_read_lock_must_hold(const struct srcu_struct *ssp) __must_hold_shared(ssp) { }
> > /**
> > * srcu_dereference_check - fetch SRCU-protected pointer for later dereferencing
> > @@ -223,9 +233,15 @@ static inline int srcu_read_lock_held(const struct srcu_struct *ssp)
> > * to 1. The @c argument will normally be a logical expression containing
> > * lockdep_is_held() calls.
> > */
> > -#define srcu_dereference_check(p, ssp, c) \
> > - __rcu_dereference_check((p), __UNIQUE_ID(rcu), \
> > - (c) || srcu_read_lock_held(ssp), __rcu)
> > +#define srcu_dereference_check(p, ssp, c) \
> > +({ \
> > + __srcu_read_lock_must_hold(ssp); \
> > + __acquire_shared_ctx_lock(RCU); \
> > + __auto_type __v = __rcu_dereference_check((p), __UNIQUE_ID(rcu), \
> > + (c) || srcu_read_lock_held(ssp), __rcu); \
> > + __release_shared_ctx_lock(RCU); \
> > + __v; \
> > +})
>
> Hi Marco,
>
> The above change is something I'm not happy about. The original
> implementation of the srcu_dereference_check() macro shows that it is
> sufficient to either hold an SRCU reader lock or the updater lock ('c').
> The addition of "__srcu_read_lock_must_hold()" will cause compilation to
> fail if the caller doesn't hold an SRCU reader lock. I'm concerned that
> this will either lead to adding __no_context_analysis to SRCU updater
> code that uses srcu_dereference_check() or to adding misleading
> __assume_ctx_lock(ssp) annotations in SRCU updater code.
Right, and it doesn't help 'c' is an arbitrary condition. But it's
fundamentally difficult to say "hold either this or that lock".
That being said, I don't think it's wrong to write e.g.:
spin_lock(&updater_lock);
__acquire_shared(ssp);
...
// writes happen through rcu_assign_pointer()
// reads can happen through srcu_dereference_check()
...
__release_shared(ssp);
spin_unlock(&updater_lock);
, given holding the updater lock implies reader access.
And given the analysis is opt-in (CONTEXT_ANALYSIS := y), I think
it's a manageable problem.
If you have a different idea how we can solve this, please let us know.
One final note, usage of srcu_dereference_check() is rare enough:
arch/x86/kvm/hyperv.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
arch/x86/kvm/x86.c: kvm_free_msr_filter(srcu_dereference_check(kvm->arch.msr_filter, &kvm->srcu, 1));
arch/x86/kvm/x86.c: kfree(srcu_dereference_check(kvm->arch.pmu_event_filter, &kvm->srcu, 1));
drivers/gpio/gpiolib.c: label = srcu_dereference_check(desc->label, &desc->gdev->desc_srcu,
drivers/hv/mshv_irq.c: girq_tbl = srcu_dereference_check(partition->pt_girq_tbl,
drivers/hwtracing/stm/core.c: link = srcu_dereference_check(src->link, &stm_source_srcu, 1);
drivers/infiniband/hw/hfi1/user_sdma.c: pq = srcu_dereference_check(fd->pq, &fd->pq_srcu,
fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
fs/quota/dquot.c: put[cnt] = srcu_dereference_check(dquots[cnt], &dquot_srcu,
fs/quota/dquot.c: transfer_from[cnt] = srcu_dereference_check(dquots[cnt],
include/linux/kvm_host.h: return srcu_dereference_check(kvm->memslots[as_id], &kvm->srcu,
virt/kvm/irqchip.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
, that I think it's easy enough to annotate these places with the above
suggestions in case you're trying out global enablement.
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] selftests: net: Move some UAPI header inclusions after libc ones
From: Matthieu Baerts @ 2026-01-26 18:13 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: netdev, linux-kernel, linux-api, Arnd Bergmann, linux-kselftest,
mptcp, linux-security-module, bpf, libc-alpha,
Carlos O'Donell, Adhemerval Zanella, Rich Felker, klibc,
Florian Weimer, Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni,
Willem de Bruijn, David S. Miller, Jakub Kicinski, Simon Horman,
Shuah Khan, Mat Martineau, Geliang Tang, Mickaël Salaün,
Günther Noack, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa
In-Reply-To: <20260120-uapi-sockaddr-v2-1-63c319111cf6@linutronix.de>
Hi Thomas,
On 20/01/2026 15:10, Thomas Weißschuh wrote:
> Interleaving inclusions of UAPI headers and libc headers is problematic.
> Both sets of headers define conflicting symbols. To enable their
> coexistence a compatibility-mechanism is in place.
>
> An upcoming change will define 'struct sockaddr' from linux/socket.h.
> However sys/socket.h from libc does not yet handle this case and a
> symbol conflict will arise.
>
> Furthermore libc-compat.h evaluates the state of the libc
> inclusions only once, at the point it is included first. If another
> problematic header from libc is included later, symbol conflicts arise.
> This will trigger other duplicate definitions when linux/libc-compat.h
> is added to linux/socket.h
>
> Move the inclusion of UAPI headers after the inclusion of the glibc
> ones, so the libc-compat.h continues to work correctly.
Thank you for looking at this!
Here is my (late, sorry) review for the modifications related to MPTCP:
> diff --git a/tools/testing/selftests/net/mptcp/mptcp_diag.c b/tools/testing/selftests/net/mptcp/mptcp_diag.c
> index 8e0b1b8d84b6..af25ebfd2915 100644
> --- a/tools/testing/selftests/net/mptcp/mptcp_diag.c
> +++ b/tools/testing/selftests/net/mptcp/mptcp_diag.c
> @@ -1,11 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> /* Copyright (c) 2025, Kylin Software */
>
> -#include <linux/sock_diag.h>
> -#include <linux/rtnetlink.h>
> -#include <linux/inet_diag.h>
> -#include <linux/netlink.h>
> -#include <linux/compiler.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <linux/tcp.h>
There is a remaining one (linux/tcp.h) here that you might want to move
below too.
> @@ -17,6 +12,12 @@
> #include <errno.h>
> #include <stdio.h>
>
> +#include <linux/sock_diag.h>
> +#include <linux/rtnetlink.h>
> +#include <linux/inet_diag.h>
> +#include <linux/netlink.h>
> +#include <linux/compiler.h>
Note that I just noticed this is the only file from this directory where
the "includes" are not sorted by type and alphabetical order, see
pm_nl_ctl.c as an example. A bit of a detail, but if you plan to send a
v2, do you mind doing that too here while at it, please?
If not, I can look at that later, but better to avoid doing that in
parallel.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [PATCH v2 3/3] landlock: transpose the layer masks data structure
From: Randy Dunlap @ 2026-01-26 17:55 UTC (permalink / raw)
To: Günther Noack
Cc: Mickaël Salaün, linux-security-module, Tingmao Wang,
Justin Suess, Samasth Norway Ananda, Matthieu Buffet,
Mikhail Ivanov, konstantin.meskhidze
In-Reply-To: <20260126.fd8c7b7537e1@gnoack.org>
On 1/26/26 8:52 AM, Günther Noack wrote:
> On Sun, Jan 25, 2026 at 02:02:50PM -0800, Randy Dunlap wrote:
>> The first line here is confusing: "in @rule in @masks"
>> Maybe:
>>
>> On 1/25/26 11:58 AM, Günther Noack wrote:
>>> +/**
>>> + * landlock_unmask_layers - Cross off access rights granted in @rule in @masks
>>
>> - Update (or Remove) access rights in @masks that are
>> granted in @rules
>>
>> ?
>
> Thanks, that is a better wording indeed.
>
> Will be included in next patch set version,
> I think this is less grammatically ambiguous:
>
> - * landlock_unmask_layers - Cross off access rights granted in @rule in @masks
> + * landlock_unmask_layers - Remove the access rights in @masks
> + * which are granted in @rule
>
Ack, that's good. Thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
From: Bart Van Assche @ 2026-01-26 17:31 UTC (permalink / raw)
To: Marco Elver, Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon
Cc: David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <20251219154418.3592607-16-elver@google.com>
On 12/19/25 7:40 AM, Marco Elver wrote:
> +/*
> + * No-op helper to denote that ssp must be held. Because SRCU-protected pointers
> + * should still be marked with __rcu_guarded, and we do not want to mark them
> + * with __guarded_by(ssp) as it would complicate annotations for writers, we
> + * choose the following strategy: srcu_dereference_check() calls this helper
> + * that checks that the passed ssp is held, and then fake-acquires 'RCU'.
> + */
> +static inline void __srcu_read_lock_must_hold(const struct srcu_struct *ssp) __must_hold_shared(ssp) { }
>
> /**
> * srcu_dereference_check - fetch SRCU-protected pointer for later dereferencing
> @@ -223,9 +233,15 @@ static inline int srcu_read_lock_held(const struct srcu_struct *ssp)
> * to 1. The @c argument will normally be a logical expression containing
> * lockdep_is_held() calls.
> */
> -#define srcu_dereference_check(p, ssp, c) \
> - __rcu_dereference_check((p), __UNIQUE_ID(rcu), \
> - (c) || srcu_read_lock_held(ssp), __rcu)
> +#define srcu_dereference_check(p, ssp, c) \
> +({ \
> + __srcu_read_lock_must_hold(ssp); \
> + __acquire_shared_ctx_lock(RCU); \
> + __auto_type __v = __rcu_dereference_check((p), __UNIQUE_ID(rcu), \
> + (c) || srcu_read_lock_held(ssp), __rcu); \
> + __release_shared_ctx_lock(RCU); \
> + __v; \
> +})
Hi Marco,
The above change is something I'm not happy about. The original
implementation of the srcu_dereference_check() macro shows that it is
sufficient to either hold an SRCU reader lock or the updater lock ('c').
The addition of "__srcu_read_lock_must_hold()" will cause compilation to
fail if the caller doesn't hold an SRCU reader lock. I'm concerned that
this will either lead to adding __no_context_analysis to SRCU updater
code that uses srcu_dereference_check() or to adding misleading
__assume_ctx_lock(ssp) annotations in SRCU updater code.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH v2 3/3] landlock: transpose the layer masks data structure
From: Günther Noack @ 2026-01-26 16:52 UTC (permalink / raw)
To: Randy Dunlap
Cc: Mickaël Salaün, linux-security-module, Tingmao Wang,
Justin Suess, Samasth Norway Ananda, Matthieu Buffet,
Mikhail Ivanov, konstantin.meskhidze
In-Reply-To: <7b7b8fd5-7e1f-4572-a342-11a0fd24b0ac@infradead.org>
On Sun, Jan 25, 2026 at 02:02:50PM -0800, Randy Dunlap wrote:
> The first line here is confusing: "in @rule in @masks"
> Maybe:
>
> On 1/25/26 11:58 AM, Günther Noack wrote:
> > +/**
> > + * landlock_unmask_layers - Cross off access rights granted in @rule in @masks
>
> - Update (or Remove) access rights in @masks that are
> granted in @rules
>
> ?
Thanks, that is a better wording indeed.
Will be included in next patch set version,
I think this is less grammatically ambiguous:
- * landlock_unmask_layers - Cross off access rights granted in @rule in @masks
+ * landlock_unmask_layers - Remove the access rights in @masks
+ * which are granted in @rule
–Günther
^ permalink raw reply
* Re: [PATCH v2 2/3] landlock: access_mask_subset() helper
From: Günther Noack @ 2026-01-26 16:48 UTC (permalink / raw)
To: Randy Dunlap
Cc: Mickaël Salaün, linux-security-module, Tingmao Wang,
Justin Suess, Samasth Norway Ananda, Matthieu Buffet,
Mikhail Ivanov, konstantin.meskhidze
In-Reply-To: <d9bc1018-82ee-43fd-8a02-097bb54190ee@infradead.org>
On Sun, Jan 25, 2026 at 01:48:52PM -0800, Randy Dunlap wrote:
> Hi,
>
> On 1/25/26 11:58 AM, Günther Noack wrote:
> > diff --git a/security/landlock/access.h b/security/landlock/access.h
> > index 7961c6630a2d..5c0caef9eaf6 100644
> > --- a/security/landlock/access.h
> > +++ b/security/landlock/access.h
> > @@ -97,4 +97,10 @@ landlock_upgrade_handled_access_masks(struct access_masks access_masks)
> > return access_masks;
> > }
> >
> > +/** access_mask_subset - true iff a has a subset of the bits of b. */
> > +static inline bool access_mask_subset(access_mask_t a, access_mask_t b)
> > +{
> > + return (a | b) == b;
> > +}
>
> Don't use "/**" for comments that are not in kernel-doc format.
> This function doesn't need kernel-doc comments, so just use "/*"
> here, please.
Thanks for the correction, will be fixed for next revision. :)
–Günther
^ permalink raw reply
* Re: [PATCH] xfrm: force flush upon NETDEV_UNREGISTER event
From: Sabrina Dubroca @ 2026-01-26 14:16 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Steffen Klassert, linux-security-module, Boris Pismenny,
David S. Miller, Florian Westphal, Kristian Evensen,
Leon Romanovsky, Leon Romanovsky, Raed Salem, Raed Salem,
Saeed Mahameed, Yossi Kuperman, Network Development,
Aviad Yehezkel, Herbert Xu
In-Reply-To: <5811ec38-907e-4788-8a0e-7758f12dc9d0@I-love.SAKURA.ne.jp>
2026-01-22, 22:07:46 +0900, Tetsuo Handa wrote:
> On 2026/01/22 20:32, Steffen Klassert wrote:
> > On Thu, Jan 22, 2026 at 08:28:31PM +0900, Tetsuo Handa wrote:
> >> On 2026/01/22 20:15, Steffen Klassert wrote:
> >>> Hm, I'd say we should not try to offload to a device that does
> >>> not support NETIF_F_HW_ESP.
> >>
> >> I was about to post the patch below, but you are suggesting that "do not allow calling
> >> xfrm_dev_state_add()/xfrm_dev_policy_add() if (dev->features & NETIF_F_HW_ESP) == 0" ?
> >
> > As said, I think this is the correct way to do it. But let's wait
> > on opinions from the hardware people.
But the current behavior ("ignore NETIF_F_HW_ESP and call
xdo_dev_state_add for new states anyway") has been established for
multiple years. Changing that now seems a bit risky.
> OK. I guess something like below.
>
> net/xfrm/xfrm_device.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
> index 52ae0e034d29..19aa61609d24 100644
> --- a/net/xfrm/xfrm_device.c
> +++ b/net/xfrm/xfrm_device.c
> @@ -292,6 +292,13 @@ int xfrm_dev_state_add(struct net *net, struct xfrm_state *x,
> dst_release(dst);
> }
>
> + if (!(dev->features & NETIF_F_HW_ESP)) {
> + NL_SET_ERR_MSG(extack, "Device doesn't support offload");
> + xso->dev = NULL;
> + dev_put(dev);
> + return -EINVAL;
> + }
I'm not sure we want to make state creation fail in this case...
> +
> if (!dev->xfrmdev_ops || !dev->xfrmdev_ops->xdo_dev_state_add) {
while it will succeed (just without offload) in that case.
> xso->dev = NULL;
> dev_put(dev);
> @@ -367,7 +374,8 @@ int xfrm_dev_policy_add(struct net *net, struct xfrm_policy *xp,
> if (!dev)
> return -EINVAL;
>
> - if (!dev->xfrmdev_ops || !dev->xfrmdev_ops->xdo_dev_policy_add) {
> + if (!dev->xfrmdev_ops || !dev->xfrmdev_ops->xdo_dev_policy_add ||
> + !(dev->features & NETIF_F_HW_ESP)) {
> xdo->dev = NULL;
> dev_put(dev);
> NL_SET_ERR_MSG(extack, "Policy offload is not supported");
--
Sabrina
^ permalink raw reply
* Re: [PATCH] xfrm: force flush upon NETDEV_UNREGISTER event
From: Leon Romanovsky @ 2026-01-26 11:07 UTC (permalink / raw)
To: Tetsuo Handa, Steffen Klassert
Cc: linux-security-module, Boris Pismenny, David S. Miller,
Florian Westphal, Kristian Evensen, Raed Salem, Raed Salem,
Saeed Mahameed, Yossi Kuperman, Network Development,
Aviad Yehezkel, Herbert Xu
In-Reply-To: <5811ec38-907e-4788-8a0e-7758f12dc9d0@I-love.SAKURA.ne.jp>
On Thu, Jan 22, 2026 at 10:07:46PM +0900, Tetsuo Handa wrote:
> On 2026/01/22 20:32, Steffen Klassert wrote:
> > On Thu, Jan 22, 2026 at 08:28:31PM +0900, Tetsuo Handa wrote:
> >> On 2026/01/22 20:15, Steffen Klassert wrote:
> >>> Hm, I'd say we should not try to offload to a device that does
> >>> not support NETIF_F_HW_ESP.
> >>
> >> I was about to post the patch below, but you are suggesting that "do not allow calling
> >> xfrm_dev_state_add()/xfrm_dev_policy_add() if (dev->features & NETIF_F_HW_ESP) == 0" ?
> >
> > As said, I think this is the correct way to do it. But let's wait
> > on opinions from the hardware people.
>
> OK. I guess something like below.
>
> net/xfrm/xfrm_device.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
> index 52ae0e034d29..19aa61609d24 100644
> --- a/net/xfrm/xfrm_device.c
> +++ b/net/xfrm/xfrm_device.c
> @@ -292,6 +292,13 @@ int xfrm_dev_state_add(struct net *net, struct xfrm_state *x,
> dst_release(dst);
> }
>
> + if (!(dev->features & NETIF_F_HW_ESP)) {
> + NL_SET_ERR_MSG(extack, "Device doesn't support offload");
> + xso->dev = NULL;
> + dev_put(dev);
> + return -EINVAL;
> + }
Steffen, Tetsuo
If by "HW people" you mean me, we always set NETIF_F_HW_ESP when adding
the .xfrm_dev_*_add() callbacks.
1334 void mlx5e_ipsec_build_netdev(struct mlx5e_priv *priv)
1335 {
1336 struct mlx5_core_dev *mdev = priv->mdev;
1337 struct net_device *netdev = priv->netdev;
1338
1339 if (!mlx5_ipsec_device_caps(mdev))
1340 return;
1341
1342 mlx5_core_info(mdev,
1343 "mlx5e: IPSec ESP acceleration enabled\n");
1344
1345 netdev->xfrmdev_ops = &mlx5e_ipsec_xfrmdev_ops;
1346 netdev->features |= NETIF_F_HW_ESP;
1347 netdev->hw_enc_features |= NETIF_F_HW_ESP;
So we are left with two possibilities: either the device registered XFRM
ops without setting NETIF_F_HW_ESP, or netdev->features was modified
without clearing the xfrmdev_ops pointer.
Which device is triggering the syzcaller crash?
Thanks
> +
> if (!dev->xfrmdev_ops || !dev->xfrmdev_ops->xdo_dev_state_add) {
> xso->dev = NULL;
> dev_put(dev);
> @@ -367,7 +374,8 @@ int xfrm_dev_policy_add(struct net *net, struct xfrm_policy *xp,
> if (!dev)
> return -EINVAL;
>
> - if (!dev->xfrmdev_ops || !dev->xfrmdev_ops->xdo_dev_policy_add) {
> + if (!dev->xfrmdev_ops || !dev->xfrmdev_ops->xdo_dev_policy_add ||
> + !(dev->features & NETIF_F_HW_ESP)) {
> xdo->dev = NULL;
> dev_put(dev);
> NL_SET_ERR_MSG(extack, "Policy offload is not supported");
>
>
>
> On 2026/01/22 20:15, Steffen Klassert wrote:
> >> But I have a question regarding security_xfrm_state_delete()/security_xfrm_policy_delete().
> >>
> >> xfrm_dev_state_flush_secctx_check() calls security_xfrm_state_delete() which can make
> >> xfrm_dev_state_flush() no-op by returning an error value.
> >> xfrm_dev_policy_flush_secctx_check() calls security_xfrm_policy_delete() which can make
> >> xfrm_dev_policy_flush() no-op by returning an error value.
> >>
> >> Since xfrm_dev_state_flush()/xfrm_dev_policy_flush() are called by NETDEV_UNREGISTER
> >> event (which is a signal for releasing all resources that prevent "struct net_device"
> >> references from dropping), making xfrm_dev_state_flush()/xfrm_dev_policy_flush() no-op (by
> >> allowing security_xfrm_state_delete()/security_xfrm_policy_delete() to return an error) is
> >> a denial-of-service bug.
> >
> > This means that the calling task doesn't have the permission to delete the
> > state, some LSM has a policy the does not grant this permission.
>
> But NETDEV_UNREGISTER event can fire without explicit request from a user.
> Roughly speaking, current behavior is that
>
> while (security_xfrm_state_delete() != 0) {
> schedule_timeout_uninterruptible(10 * HZ);
> pr_emerg("unregister_netdevice: waiting for %s to become free. Usage count = %d\n",
> dev->name, netdev_refcnt_read(dev));
> }
> while (security_xfrm_policy_delete() != 0) {
> schedule_timeout_uninterruptible(10 * HZ);
> pr_emerg("unregister_netdevice: waiting for %s to become free. Usage count = %d\n",
> dev->name, netdev_refcnt_read(dev));
> }
>
> might be executed upon e.g. termination of a userspace process.
>
> >
> >>
> >> Therefore, I wonder what are security_xfrm_state_delete() and security_xfrm_policy_delete()
> >> for. Can I kill xfrm_dev_state_flush_secctx_check() and xfrm_dev_policy_flush_secctx_check() ?
> >
> > This might violate a LSM policy then.
>
> But LSM policy that results in system hung upon automatic cleanup logic is so stupid.
> I want to kill xfrm_dev_state_flush_secctx_check() and xfrm_dev_policy_flush_secctx_check()
> in order to eliminate possibility of system hung.
>
^ permalink raw reply
* Re: [PATCH v2 00/27] Allow inlining C helpers into Rust when using LTO
From: Miguel Ojeda @ 2026-01-26 5:08 UTC (permalink / raw)
To: Alice Ryhl
Cc: rust-for-linux, linux-kernel, Boqun Feng, Gary Guo,
Peter Zijlstra, Elle Rhumsaa, Andreas Hindborg, linux-block,
FUJITA Tomonori, Miguel Ojeda, Michael Turquette, Stephen Boyd,
linux-clk, Benno Lossin, Danilo Krummrich, Thomas Gleixner,
Paul Moore, Serge Hallyn, linux-security-module, Josh Poimboeuf,
Jason Baron, Steven Rostedt, Ard Biesheuvel, Andrew Ballance,
Andrew Morton, Liam R. Howlett, maple-tree, linux-mm,
Lorenzo Stoakes, Uladzislau Rezki, Vitaly Wool, Rob Herring,
devicetree, Daniel Almeida, Michal Wilczynski, linux-pwm,
Paul E. McKenney, rcu, Will Deacon, Fiona Behrens,
Greg Kroah-Hartman, Vlastimil Babka, Christoph Lameter,
David Rientjes, Ingo Molnar, Waiman Long, Mitchell Levy,
Frederic Weisbecker, Lyude Paul, Anna-Maria Behnsen, John Stultz,
linux-usb, Tejun Heo, Lai Jiangshan, Matthew Wilcox,
Tamir Duberstein, linux-fsdevel
In-Reply-To: <20260105-define-rust-helper-v2-0-51da5f454a67@google.com>
On Mon, Jan 5, 2026 at 1:42 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> rust: bug: add __rust_helper to helpers
> rust: err: add __rust_helper to helpers
> rust: maple_tree: add __rust_helper to helpers
> rust: mm: add __rust_helper to helpers
> rust: of: add __rust_helper to helpers
> rust: rbtree: add __rust_helper to helpers
> rust: slab: add __rust_helper to helpers
> rust: uaccess: add __rust_helper to helpers
> rust: workqueue: add __rust_helper to helpers
Applied these to `rust-next` -- thanks everyone!
If someone did not intend for me to take it even if the Acked-by is
there (e.g. perhaps Andrew wanted to pick those nevertheless?), then
please shout.
With this, and if I didn't miss any message (plus looking at
linux-next where I see Greg picked usb), then only clk and jump_label
remain (plus any new incoming one).
Let's see if we can get them done next cycle then.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2 3/3] landlock: transpose the layer masks data structure
From: Randy Dunlap @ 2026-01-25 22:02 UTC (permalink / raw)
To: Günther Noack, Mickaël Salaün
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze
In-Reply-To: <20260125195853.109967-4-gnoack3000@gmail.com>
The first line here is confusing: "in @rule in @masks"
Maybe:
On 1/25/26 11:58 AM, Günther Noack wrote:
> +/**
> + * landlock_unmask_layers - Cross off access rights granted in @rule in @masks
- Update (or Remove) access rights in @masks that are
granted in @rules
?
> *
> - * Returns true if the request is allowed (i.e. relevant layer masks for the
> - * request are empty).
> + * Updates the set of (per-layer) unfulfilled access rights @masks
> + * so that all the access rights granted in @rule are removed from it
> + * (because they are now fulfilled).
> + *
> + * @rule: A rule that grants a set of access rights for each layer
> + * @masks: A matrix of unfulfilled access rights for each layer
> + *
> + * Returns true if the request is allowed (i.e. the access rights granted all
> + * remaining unfulfilled access rights and masks has no leftover set bits).
> */
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 2/3] landlock: access_mask_subset() helper
From: Randy Dunlap @ 2026-01-25 21:48 UTC (permalink / raw)
To: Günther Noack, Mickaël Salaün
Cc: linux-security-module, Tingmao Wang, Justin Suess,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze
In-Reply-To: <20260125195853.109967-3-gnoack3000@gmail.com>
Hi,
On 1/25/26 11:58 AM, Günther Noack wrote:
> diff --git a/security/landlock/access.h b/security/landlock/access.h
> index 7961c6630a2d..5c0caef9eaf6 100644
> --- a/security/landlock/access.h
> +++ b/security/landlock/access.h
> @@ -97,4 +97,10 @@ landlock_upgrade_handled_access_masks(struct access_masks access_masks)
> return access_masks;
> }
>
> +/** access_mask_subset - true iff a has a subset of the bits of b. */
> +static inline bool access_mask_subset(access_mask_t a, access_mask_t b)
> +{
> + return (a | b) == b;
> +}
Don't use "/**" for comments that are not in kernel-doc format.
This function doesn't need kernel-doc comments, so just use "/*"
here, please.
--
~Randy
^ permalink raw reply
* [PATCH] apparmor: Replace memcpy + NUL termination with kmemdup_nul in do_setattr
From: Thorsten Blum @ 2026-01-25 21:00 UTC (permalink / raw)
To: John Johansen, Paul Moore, James Morris, Serge E. Hallyn
Cc: Thorsten Blum, apparmor, linux-security-module, linux-kernel
Use kmemdup_nul() to copy 'value' instead of using memcpy() followed by
a manual NUL termination. No functional changes.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
security/apparmor/lsm.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index a87cd60ed206..98b92af5890e 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -866,12 +866,9 @@ static int do_setattr(u64 attr, void *value, size_t size)
/* AppArmor requires that the buffer must be null terminated atm */
if (args[size - 1] != '\0') {
- /* null terminate */
- largs = args = kmalloc(size + 1, GFP_KERNEL);
+ largs = args = kmemdup_nul(value, size, GFP_KERNEL);
if (!args)
return -ENOMEM;
- memcpy(args, value, size);
- args[size] = '\0';
}
error = -EINVAL;
--
Thorsten Blum <thorsten.blum@linux.dev>
GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4
^ permalink raw reply related
* Re: [GIT PULL] KEYS: trusted: keys-trusted-next-6.19-rc7
From: pr-tracker-bot @ 2026-01-25 20:21 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Linus Torvalds, David Howells, James Bottomley, Mimi Zohar,
keyrings, linux-integrity, linux-security-module
In-Reply-To: <aXZPW1HnC0kM-VDC@kernel.org>
The pull request you sent on Sun, 25 Jan 2026 19:14:03 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/keys-trusted-next-6.19-rc7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f9e6e6d210669f24697e615b68b5abbae9d7a32e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ 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