* Re: LSM namespacing API
From: Stephen Smalley @ 2026-03-09 18:15 UTC (permalink / raw)
To: Casey Schaufler
Cc: Dr. Greg, Paul Moore, Ondrej Mosnacek, linux-security-module,
selinux, John Johansen
In-Reply-To: <ae5e9c1b-d0cd-476b-87d2-70c0bc8ba09c@schaufler-ca.com>
On Fri, Mar 6, 2026 at 4:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 3/6/2026 9:48 AM, Dr. Greg wrote:
> > On Tue, Mar 03, 2026 at 11:46:53AM -0500, Paul Moore wrote:
> >
> > Good morning, I hope the week is winding down well for everyone.
> >
> >> On Tue, Mar 3, 2026 at 8:30???AM Stephen Smalley
> >>> I think my only caveat here is that your proposal is quite a bit more
> >>> complex than what I implemented here:
> >>> [1] https://lore.kernel.org/selinux/20251003190959.3288-2-stephen.smalley.work@gmail.com/
> >>> [2] https://lore.kernel.org/selinux/20251003191328.3605-1-stephen.smalley.work@gmail.com/
> >>> and I'm not sure the extra complexity is worth it.
> >>>
> >>> In particular:
> >>> 1. Immediately unsharing the namespace upon lsm_set_self_attr() allows
> >>> the caller to immediately and unambiguously know if the operation is
> >>> supported and allowed ...
> >> Performing the unshare operation immediately looks much less like a
> >> LSM attribute and more like its own syscall. That isn't a problem
> >> in my eyes, it just means if this is the direction we want to go we
> >> should implement a lsm_unshare(2) API, or something similar.
> > Stephen's take on this is correct, the least complicated path forward
> > is a simple call, presumably lsm_unshare(2), that instructs the LSM(s)
> > to carry out whatever is needed to create a new security namespace.
> >
> > There are only two public implementations of what can be referred to
> > as major security namespacing efforts; Stephen's work with SeLinux and
> > our TSEM implementation.
>
> Please be just a tiny bit careful before you make this sort of assertion:
>
> https://lwn.net/Articles/645403/
I believe both AppArmor and TOMOYO also have namespacing
implementations already upstream, so SELinux is certainly not the only
one. Looks like the Smack implementation you cited above was based on
extending user namespaces rather than purely Smack-internal like the
others; is that why it wasn't ultimately merged?
^ permalink raw reply
* Re: [PATCH 0/3] Firmware LSM hook
From: Paul Moore @ 2026-03-09 18:32 UTC (permalink / raw)
To: Leon Romanovsky
Cc: James Morris, Serge E. Hallyn, Jason Gunthorpe, Saeed Mahameed,
Itay Avraham, Dave Jiang, Jonathan Cameron, linux-security-module,
linux-kernel, linux-rdma, Chiara Meiohas, Maher Sanalla,
Edward Srouji
In-Reply-To: <20260309-fw-lsm-hook-v1-0-4a6422e63725@nvidia.com>
On Mon, Mar 9, 2026 at 7:15 AM Leon Romanovsky <leon@kernel.org> wrote:
>
> From Chiara:
>
> This patch set introduces a new LSM hook to validate firmware commands
> triggered by userspace before they are submitted to the device. The hook
> runs after the command buffer is constructed, right before it is sent
> to firmware.
>
> The goal is to allow a security module to allow or deny a given command
> before it is submitted to firmware. BPF LSM can attach to this hook
> to implement such policies. This allows fine-grained policies for different
> firmware commands.
>
> In this series, the new hook is called from RDMA uverbs and from the fwctl
> subsystem. Both the uverbs and fwctl interfaces use ioctl, so an obvious
> candidate would seem to be the file_ioctl hook. However, the userspace
> attributes used to build the firmware command buffer are copied from
> userspace (copy_from_user()) deep in the driver, depending on various
> conditions. As a result, file_ioctl does not have the information required
> to make a policy decision.
>
> This newly introduced hook provides the command buffer together with relevant
> metadata (device, command class, and a class-specific device identifier), so
> security modules can distinguish between different command classes and devices.
>
> The hook can be used by other drivers that submit firmware commands via a command
> buffer.
Hi Leon,
At the link below, you'll find guidance on submitting new LSM hooks.
Please take a look and let me know if you have any questions.
https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks
(If you lose the link, or simply for future reference, you can find it
in the "SECURITY SUBSYSTEM" MAINTAINERS entry.)
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Mimi Zohar @ 2026-03-09 19:00 UTC (permalink / raw)
To: Jeff Layton
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <f22758116dabd3c135a833bcb5cfcd2ea4f6ecf4.camel@kernel.org>
On Mon, 2026-03-09 at 13:59 -0400, Jeff Layton wrote:
> On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> > [ I/O socket time out. Trimming the To list.]
> >
> > On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> > > This version squashes all of the format-string changes and the i_ino
> > > type change into the same patch. This results in a giant 600+ line patch
> > > at the end of the series, but it does remain bisectable. Because the
> > > patchset was reorganized (again) some of the R-b's and A-b's have been
> > > dropped.
> > >
> > > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > > interested in testing this.
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> > >
> > > Original cover letter follows:
> > >
> > > ----------------------8<-----------------------
> > >
> > > Christian said [1] to "just do it" when I proposed this, so here we are!
> > >
> > > For historical reasons, the inode->i_ino field is an unsigned long,
> > > which means that it's 32 bits on 32 bit architectures. This has caused a
> > > number of filesystems to implement hacks to hash a 64-bit identifier
> > > into a 32-bit field, and deprives us of a universal identifier field for
> > > an inode.
> > >
> > > This patchset changes the inode->i_ino field from an unsigned long to a
> > > u64. This shouldn't make any material difference on 64-bit hosts, but
> > > 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> > > have effects on slabcache sizes and field alignment.
> > >
> > > The bulk of the changes are to format strings and tracepoints, since the
> > > kernel itself doesn't care that much about the i_ino field. The first
> > > patch changes some vfs function arguments, so check that one out
> > > carefully.
> > >
> > > With this change, we may be able to shrink some inode structures. For
> > > instance, struct nfs_inode has a fileid field that holds the 64-bit
> > > inode number. With this set of changes, that field could be eliminated.
> > > I'd rather leave that sort of cleanups for later just to keep this
> > > simple.
> > >
> > > Much of this set was generated by LLM, but I attributed it to myself
> > > since I consider this to be in the "menial tasks" category of LLM usage.
> > >
> > > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> > >
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> >
> > Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
> > i_ino and calculates either an HMAC or file meta-data hash, which is then
> > signed.
> >
> >
>
> Thanks Mimi, good catch.
>
> It looks like we should just be able to change the ino field to a u64
> alongside everything else. Something like this:
>
> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> index c0ca4eedb0fe..77b6c2fa345e 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> char type, char *digest)
> {
> struct h_misc {
> - unsigned long ino;
> + u64 ino;
> __u32 generation;
> uid_t uid;
> gid_t gid;
>
Agreed.
>
> That should make no material difference on 64-bit hosts. What's the
> effect on 32-bit? Will they just need to remeasure everything or would
> the consequences be more dire? Do we have any clue whether anyone is
> using EVM in 32-bit environments?
All good questions. Unfortunately I don't know the answer to most of them. What
we do know: changing the size of the i_ino field would affect EVM file metadata
verification and would require relabeling the filesystem. Even packages
containing EVM portable signatures, which don't include or verify the i_ino
number, would be affected.
Mimi
^ permalink raw reply
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Jeff Layton @ 2026-03-09 19:33 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <c9500adc562665d44feaca9206f23a5ba07432c1.camel@linux.ibm.com>
On Mon, 2026-03-09 at 15:00 -0400, Mimi Zohar wrote:
> On Mon, 2026-03-09 at 13:59 -0400, Jeff Layton wrote:
> > On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> > > [ I/O socket time out. Trimming the To list.]
> > >
> > > On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> > > > This version squashes all of the format-string changes and the i_ino
> > > > type change into the same patch. This results in a giant 600+ line patch
> > > > at the end of the series, but it does remain bisectable. Because the
> > > > patchset was reorganized (again) some of the R-b's and A-b's have been
> > > > dropped.
> > > >
> > > > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > > > interested in testing this.
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> > > >
> > > > Original cover letter follows:
> > > >
> > > > ----------------------8<-----------------------
> > > >
> > > > Christian said [1] to "just do it" when I proposed this, so here we are!
> > > >
> > > > For historical reasons, the inode->i_ino field is an unsigned long,
> > > > which means that it's 32 bits on 32 bit architectures. This has caused a
> > > > number of filesystems to implement hacks to hash a 64-bit identifier
> > > > into a 32-bit field, and deprives us of a universal identifier field for
> > > > an inode.
> > > >
> > > > This patchset changes the inode->i_ino field from an unsigned long to a
> > > > u64. This shouldn't make any material difference on 64-bit hosts, but
> > > > 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> > > > have effects on slabcache sizes and field alignment.
> > > >
> > > > The bulk of the changes are to format strings and tracepoints, since the
> > > > kernel itself doesn't care that much about the i_ino field. The first
> > > > patch changes some vfs function arguments, so check that one out
> > > > carefully.
> > > >
> > > > With this change, we may be able to shrink some inode structures. For
> > > > instance, struct nfs_inode has a fileid field that holds the 64-bit
> > > > inode number. With this set of changes, that field could be eliminated.
> > > > I'd rather leave that sort of cleanups for later just to keep this
> > > > simple.
> > > >
> > > > Much of this set was generated by LLM, but I attributed it to myself
> > > > since I consider this to be in the "menial tasks" category of LLM usage.
> > > >
> > > > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> > > >
> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > >
> > > Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
> > > i_ino and calculates either an HMAC or file meta-data hash, which is then
> > > signed.
> > >
> > >
> >
> > Thanks Mimi, good catch.
> >
> > It looks like we should just be able to change the ino field to a u64
> > alongside everything else. Something like this:
> >
> > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> > index c0ca4eedb0fe..77b6c2fa345e 100644
> > --- a/security/integrity/evm/evm_crypto.c
> > +++ b/security/integrity/evm/evm_crypto.c
> > @@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> > char type, char *digest)
> > {
> > struct h_misc {
> > - unsigned long ino;
> > + u64 ino;
> > __u32 generation;
> > uid_t uid;
> > gid_t gid;
> >
>
> Agreed.
>
> >
> > That should make no material difference on 64-bit hosts. What's the
> > effect on 32-bit? Will they just need to remeasure everything or would
> > the consequences be more dire? Do we have any clue whether anyone is
> > using EVM in 32-bit environments?
>
> All good questions. Unfortunately I don't know the answer to most of them. What
> we do know: changing the size of the i_ino field would affect EVM file metadata
> verification and would require relabeling the filesystem. Even packages
> containing EVM portable signatures, which don't include or verify the i_ino
> number, would be affected.
>
Ouch. Technically, I guess this is ABI...
While converting to u64 seems like the ideal thing to do, the other
option might be to just keep this as an unsigned long for now.
No effect on 64-bit, but that could keep things working 32-bit when the
i_ino casts properly to a u32. ext4 would be fine since they don't
issue inode numbers larger than UINT_MAX. xfs and btrfs are a bit more
iffy, but worst case they'd just need to be relabeled (which is what
they'll need to do anyway).
If we do that, then we should probably add a comment to this function
explaining why it's an unsigned long.
Thoughts?
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/3] Firmware LSM hook
From: Leon Romanovsky @ 2026-03-09 19:37 UTC (permalink / raw)
To: Paul Moore
Cc: James Morris, Serge E. Hallyn, Jason Gunthorpe, Saeed Mahameed,
Itay Avraham, Dave Jiang, Jonathan Cameron, linux-security-module,
linux-kernel, linux-rdma, Chiara Meiohas, Maher Sanalla,
Edward Srouji
In-Reply-To: <CAHC9VhTR9CsBgxRCAHXm5T2NZ5tr+XfmA--zkt=udmk9hPRuZQ@mail.gmail.com>
On Mon, Mar 09, 2026 at 02:32:39PM -0400, Paul Moore wrote:
> On Mon, Mar 9, 2026 at 7:15 AM Leon Romanovsky <leon@kernel.org> wrote:
> >
> > From Chiara:
> >
> > This patch set introduces a new LSM hook to validate firmware commands
> > triggered by userspace before they are submitted to the device. The hook
> > runs after the command buffer is constructed, right before it is sent
> > to firmware.
> >
> > The goal is to allow a security module to allow or deny a given command
> > before it is submitted to firmware. BPF LSM can attach to this hook
> > to implement such policies. This allows fine-grained policies for different
> > firmware commands.
> >
> > In this series, the new hook is called from RDMA uverbs and from the fwctl
> > subsystem. Both the uverbs and fwctl interfaces use ioctl, so an obvious
> > candidate would seem to be the file_ioctl hook. However, the userspace
> > attributes used to build the firmware command buffer are copied from
> > userspace (copy_from_user()) deep in the driver, depending on various
> > conditions. As a result, file_ioctl does not have the information required
> > to make a policy decision.
> >
> > This newly introduced hook provides the command buffer together with relevant
> > metadata (device, command class, and a class-specific device identifier), so
> > security modules can distinguish between different command classes and devices.
> >
> > The hook can be used by other drivers that submit firmware commands via a command
> > buffer.
>
> Hi Leon,
>
> At the link below, you'll find guidance on submitting new LSM hooks.
> Please take a look and let me know if you have any questions.
>
> https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks
I assume that you are referring to this part:
* New LSM hooks must demonstrate their usefulness by providing a meaningful
implementation for at least one in-kernel LSM. The goal is to demonstrate
the purpose and expected semantics of the hooks. Out of tree kernel code,
and pass through implementations, such as the BPF LSM, are not eligible
for LSM hook reference implementations.
The point is that we are not inspecting a kernel call, but the FW mailbox,
which has very little meaning to the kernel. From the kernel's perspective,
all relevant checks have already been performed, but the existing capability
granularity does not allow us to distinguish between FW_CMD1 and FW_CMD2.
Here we propose a generic interface that can be applied to all FWCTL
devices without out-of-tree kernel code at all.
Thanks
>
> (If you lose the link, or simply for future reference, you can find it
> in the "SECURITY SUBSYSTEM" MAINTAINERS entry.)
>
> --
> paul-moore.com
>
^ permalink raw reply
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Mimi Zohar @ 2026-03-09 20:11 UTC (permalink / raw)
To: Jeff Layton
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <dd3f9873c7939fba0ca2366effd24e4b6326f17b.camel@kernel.org>
On Mon, 2026-03-09 at 15:33 -0400, Jeff Layton wrote:
> On Mon, 2026-03-09 at 15:00 -0400, Mimi Zohar wrote:
> > On Mon, 2026-03-09 at 13:59 -0400, Jeff Layton wrote:
> > > On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> > > > [ I/O socket time out. Trimming the To list.]
> > > >
> > > > On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> > > > > This version squashes all of the format-string changes and the i_ino
> > > > > type change into the same patch. This results in a giant 600+ line patch
> > > > > at the end of the series, but it does remain bisectable. Because the
> > > > > patchset was reorganized (again) some of the R-b's and A-b's have been
> > > > > dropped.
> > > > >
> > > > > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > > > > interested in testing this.
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> > > > >
> > > > > Original cover letter follows:
> > > > >
> > > > > ----------------------8<-----------------------
> > > > >
> > > > > Christian said [1] to "just do it" when I proposed this, so here we are!
> > > > >
> > > > > For historical reasons, the inode->i_ino field is an unsigned long,
> > > > > which means that it's 32 bits on 32 bit architectures. This has caused a
> > > > > number of filesystems to implement hacks to hash a 64-bit identifier
> > > > > into a 32-bit field, and deprives us of a universal identifier field for
> > > > > an inode.
> > > > >
> > > > > This patchset changes the inode->i_ino field from an unsigned long to a
> > > > > u64. This shouldn't make any material difference on 64-bit hosts, but
> > > > > 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> > > > > have effects on slabcache sizes and field alignment.
> > > > >
> > > > > The bulk of the changes are to format strings and tracepoints, since the
> > > > > kernel itself doesn't care that much about the i_ino field. The first
> > > > > patch changes some vfs function arguments, so check that one out
> > > > > carefully.
> > > > >
> > > > > With this change, we may be able to shrink some inode structures. For
> > > > > instance, struct nfs_inode has a fileid field that holds the 64-bit
> > > > > inode number. With this set of changes, that field could be eliminated.
> > > > > I'd rather leave that sort of cleanups for later just to keep this
> > > > > simple.
> > > > >
> > > > > Much of this set was generated by LLM, but I attributed it to myself
> > > > > since I consider this to be in the "menial tasks" category of LLM usage.
> > > > >
> > > > > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> > > > >
> > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > >
> > > > Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
> > > > i_ino and calculates either an HMAC or file meta-data hash, which is then
> > > > signed.
> > > >
> > > >
> > >
> > > Thanks Mimi, good catch.
> > >
> > > It looks like we should just be able to change the ino field to a u64
> > > alongside everything else. Something like this:
> > >
> > > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> > > index c0ca4eedb0fe..77b6c2fa345e 100644
> > > --- a/security/integrity/evm/evm_crypto.c
> > > +++ b/security/integrity/evm/evm_crypto.c
> > > @@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> > > char type, char *digest)
> > > {
> > > struct h_misc {
> > > - unsigned long ino;
> > > + u64 ino;
> > > __u32 generation;
> > > uid_t uid;
> > > gid_t gid;
> > >
> >
> > Agreed.
> >
> > >
> > > That should make no material difference on 64-bit hosts. What's the
> > > effect on 32-bit? Will they just need to remeasure everything or would
> > > the consequences be more dire? Do we have any clue whether anyone is
> > > using EVM in 32-bit environments?
> >
> > All good questions. Unfortunately I don't know the answer to most of them. What
> > we do know: changing the size of the i_ino field would affect EVM file metadata
> > verification and would require relabeling the filesystem. Even packages
> > containing EVM portable signatures, which don't include or verify the i_ino
> > number, would be affected.
> >
>
> Ouch. Technically, I guess this is ABI...
>
> While converting to u64 seems like the ideal thing to do, the other
> option might be to just keep this as an unsigned long for now.
>
> No effect on 64-bit, but that could keep things working 32-bit when the
> i_ino casts properly to a u32. ext4 would be fine since they don't
> issue inode numbers larger than UINT_MAX. xfs and btrfs are a bit more
> iffy, but worst case they'd just need to be relabeled (which is what
> they'll need to do anyway).
>
> If we do that, then we should probably add a comment to this function
> explaining why it's an unsigned long.
Agreed.
>
> Thoughts?
My concern would be embedded/IoT devices, but I don't have any insight into who
might be using it on 32 bit.
Mimi
^ permalink raw reply
* [PATCH] integrity: Eliminate weak definition of arch_get_secureboot()
From: Nathan Chancellor @ 2026-03-09 20:37 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg
Cc: Arnd Bergmann, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Paul Moore, James Morris, Serge E. Hallyn,
Coiby Xu, linux-kernel, linuxppc-dev, linux-s390, linux-integrity,
linux-security-module, llvm, Nathan Chancellor
security/integrity/secure_boot.c contains a single __weak function,
which breaks recordmcount when building with clang:
$ make -skj"$(nproc)" ARCH=powerpc LLVM=1 ppc64_defconfig security/integrity/secure_boot.o
Cannot find symbol for section 2: .text.
security/integrity/secure_boot.o: failed
Introduce a Kconfig symbol, CONFIG_HAVE_ARCH_GET_SECUREBOOT, to indicate
that an architecture provides a definition of arch_get_secureboot().
Provide a static inline stub when this symbol is not defined to achieve
the same effect as the __weak function, allowing secure_boot.c to be
removed altogether. Move the s390 definition of arch_get_secureboot()
out of the CONFIG_KEXEC_FILE block to ensure it is always available, as
it does not actually depend on KEXEC_FILE.
Fixes: 31a6a07eefeb ("integrity: Make arch_ima_get_secureboot integrity-wide")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
arch/Kconfig | 3 +++
arch/powerpc/Kconfig | 1 +
arch/s390/Kconfig | 1 +
arch/s390/kernel/ipl.c | 10 +++++-----
include/linux/secure_boot.h | 4 ++++
security/integrity/Makefile | 2 +-
security/integrity/secure_boot.c | 16 ----------------
7 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 102ddbd4298e..a6d1c8cc1d64 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1841,4 +1841,7 @@ config ARCH_WANTS_PRE_LINK_VMLINUX
config ARCH_HAS_CPU_ATTACK_VECTORS
bool
+config HAVE_ARCH_GET_SECUREBOOT
+ def_bool EFI
+
endmenu
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index ad7a2fe63a2a..da1eafb64354 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1061,6 +1061,7 @@ config PPC_SECURE_BOOT
depends on IMA_ARCH_POLICY
imply IMA_SECURE_AND_OR_TRUSTED_BOOT
select PSERIES_PLPKS if PPC_PSERIES
+ select HAVE_ARCH_GET_SECUREBOOT
help
Systems with firmware secure boot enabled need to define security
policies to extend secure boot to the OS. This config allows a user
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 2101cc738b5e..4197c20d34b4 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -181,6 +181,7 @@ config S390
select GENERIC_IOREMAP if PCI
select HAVE_ALIGNED_STRUCT_PAGE
select HAVE_ARCH_AUDITSYSCALL
+ select HAVE_ARCH_GET_SECUREBOOT
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN
diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
index 2d01a1713938..3c346b02ceb9 100644
--- a/arch/s390/kernel/ipl.c
+++ b/arch/s390/kernel/ipl.c
@@ -2388,6 +2388,11 @@ void __no_stack_protector s390_reset_system(void)
diag_amode31_ops.diag308_reset();
}
+bool arch_get_secureboot(void)
+{
+ return ipl_secure_flag;
+}
+
#ifdef CONFIG_KEXEC_FILE
int ipl_report_add_component(struct ipl_report *report, struct kexec_buf *kbuf,
@@ -2505,11 +2510,6 @@ void *ipl_report_finish(struct ipl_report *report)
return buf;
}
-bool arch_get_secureboot(void)
-{
- return ipl_secure_flag;
-}
-
int ipl_report_free(struct ipl_report *report)
{
struct ipl_report_component *comp, *ncomp;
diff --git a/include/linux/secure_boot.h b/include/linux/secure_boot.h
index 3ded3f03655c..d17e92351567 100644
--- a/include/linux/secure_boot.h
+++ b/include/linux/secure_boot.h
@@ -10,10 +10,14 @@
#include <linux/types.h>
+#ifdef CONFIG_HAVE_ARCH_GET_SECUREBOOT
/*
* Returns true if the platform secure boot is enabled.
* Returns false if disabled or not supported.
*/
bool arch_get_secureboot(void);
+#else
+static inline bool arch_get_secureboot(void) { return false; }
+#endif
#endif /* _LINUX_SECURE_BOOT_H */
diff --git a/security/integrity/Makefile b/security/integrity/Makefile
index 548665e2b702..45dfdedbdad4 100644
--- a/security/integrity/Makefile
+++ b/security/integrity/Makefile
@@ -5,7 +5,7 @@
obj-$(CONFIG_INTEGRITY) += integrity.o
-integrity-y := iint.o secure_boot.o
+integrity-y := iint.o
integrity-$(CONFIG_INTEGRITY_AUDIT) += integrity_audit.o
integrity-$(CONFIG_INTEGRITY_SIGNATURE) += digsig.o
integrity-$(CONFIG_INTEGRITY_ASYMMETRIC_KEYS) += digsig_asymmetric.o
diff --git a/security/integrity/secure_boot.c b/security/integrity/secure_boot.c
deleted file mode 100644
index fc2693c286f8..000000000000
--- a/security/integrity/secure_boot.c
+++ /dev/null
@@ -1,16 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2026 Red Hat, Inc. All Rights Reserved.
- *
- * Author: Coiby Xu <coxu@redhat.com>
- */
-#include <linux/secure_boot.h>
-
-/*
- * Default weak implementation.
- * Architectures that support secure boot must override this.
- */
-__weak bool arch_get_secureboot(void)
-{
- return false;
-}
---
base-commit: 870819434c8dfcc3158033b66e7851b81bb17e21
change-id: 20260309-integrity-drop-weak-arch-get-secureboot-cead298d493f
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply related
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Jeff Layton @ 2026-03-09 20:50 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <0bd92b4fce00a6111a0fc7764904f7e6ae0ece3a.camel@linux.ibm.com>
On Mon, 2026-03-09 at 16:11 -0400, Mimi Zohar wrote:
> On Mon, 2026-03-09 at 15:33 -0400, Jeff Layton wrote:
> > On Mon, 2026-03-09 at 15:00 -0400, Mimi Zohar wrote:
> > > On Mon, 2026-03-09 at 13:59 -0400, Jeff Layton wrote:
> > > > On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> > > > > [ I/O socket time out. Trimming the To list.]
> > > > >
> > > > > On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> > > > > > This version squashes all of the format-string changes and the i_ino
> > > > > > type change into the same patch. This results in a giant 600+ line patch
> > > > > > at the end of the series, but it does remain bisectable. Because the
> > > > > > patchset was reorganized (again) some of the R-b's and A-b's have been
> > > > > > dropped.
> > > > > >
> > > > > > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > > > > > interested in testing this.
> > > > > >
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> > > > > >
> > > > > > Original cover letter follows:
> > > > > >
> > > > > > ----------------------8<-----------------------
> > > > > >
> > > > > > Christian said [1] to "just do it" when I proposed this, so here we are!
> > > > > >
> > > > > > For historical reasons, the inode->i_ino field is an unsigned long,
> > > > > > which means that it's 32 bits on 32 bit architectures. This has caused a
> > > > > > number of filesystems to implement hacks to hash a 64-bit identifier
> > > > > > into a 32-bit field, and deprives us of a universal identifier field for
> > > > > > an inode.
> > > > > >
> > > > > > This patchset changes the inode->i_ino field from an unsigned long to a
> > > > > > u64. This shouldn't make any material difference on 64-bit hosts, but
> > > > > > 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> > > > > > have effects on slabcache sizes and field alignment.
> > > > > >
> > > > > > The bulk of the changes are to format strings and tracepoints, since the
> > > > > > kernel itself doesn't care that much about the i_ino field. The first
> > > > > > patch changes some vfs function arguments, so check that one out
> > > > > > carefully.
> > > > > >
> > > > > > With this change, we may be able to shrink some inode structures. For
> > > > > > instance, struct nfs_inode has a fileid field that holds the 64-bit
> > > > > > inode number. With this set of changes, that field could be eliminated.
> > > > > > I'd rather leave that sort of cleanups for later just to keep this
> > > > > > simple.
> > > > > >
> > > > > > Much of this set was generated by LLM, but I attributed it to myself
> > > > > > since I consider this to be in the "menial tasks" category of LLM usage.
> > > > > >
> > > > > > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> > > > > >
> > > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > >
> > > > > Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
> > > > > i_ino and calculates either an HMAC or file meta-data hash, which is then
> > > > > signed.
> > > > >
> > > > >
> > > >
> > > > Thanks Mimi, good catch.
> > > >
> > > > It looks like we should just be able to change the ino field to a u64
> > > > alongside everything else. Something like this:
> > > >
> > > > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> > > > index c0ca4eedb0fe..77b6c2fa345e 100644
> > > > --- a/security/integrity/evm/evm_crypto.c
> > > > +++ b/security/integrity/evm/evm_crypto.c
> > > > @@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> > > > char type, char *digest)
> > > > {
> > > > struct h_misc {
> > > > - unsigned long ino;
> > > > + u64 ino;
> > > > __u32 generation;
> > > > uid_t uid;
> > > > gid_t gid;
> > > >
> > >
> > > Agreed.
> > >
> > > >
> > > > That should make no material difference on 64-bit hosts. What's the
> > > > effect on 32-bit? Will they just need to remeasure everything or would
> > > > the consequences be more dire? Do we have any clue whether anyone is
> > > > using EVM in 32-bit environments?
> > >
> > > All good questions. Unfortunately I don't know the answer to most of them. What
> > > we do know: changing the size of the i_ino field would affect EVM file metadata
> > > verification and would require relabeling the filesystem. Even packages
> > > containing EVM portable signatures, which don't include or verify the i_ino
> > > number, would be affected.
> > >
> >
> > Ouch. Technically, I guess this is ABI...
> >
> > While converting to u64 seems like the ideal thing to do, the other
> > option might be to just keep this as an unsigned long for now.
> >
> > No effect on 64-bit, but that could keep things working 32-bit when the
> > i_ino casts properly to a u32. ext4 would be fine since they don't
> > issue inode numbers larger than UINT_MAX. xfs and btrfs are a bit more
> > iffy, but worst case they'd just need to be relabeled (which is what
> > they'll need to do anyway).
> >
> > If we do that, then we should probably add a comment to this function
> > explaining why it's an unsigned long.
>
> Agreed.
>
For now, I think that's the best approach. I'll spin up a patch to add
the comment.
> >
> > Thoughts?
>
> My concern would be embedded/IoT devices, but I don't have any insight into who
> might be using it on 32 bit.
>
Yep. This LWN article on Arnd's talk lays out the state of things:
https://lwn.net/Articles/1035727/
The upshot is that it's hard to buy 32-bit CPUs these days, and will
only get harder. But, there are still a fair number of 32-bit devices
out in the field and will be for some time.
The big question is how many of those EVM users that intend to run new
kernels. I have no idea how to answer that.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH] integrity: avoid using __weak functions
From: Nathan Chancellor @ 2026-03-09 21:29 UTC (permalink / raw)
To: Mimi Zohar
Cc: Arnd Bergmann, Madhavan Srinivasan, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev, Arnd Bergmann,
Roberto Sassu, Dmitry Kasatkin, Paul Moore, James Morris,
Serge E. Hallyn, Jarkko Sakkinen, Ard Biesheuvel, Coiby Xu,
Nicholas Piggin, Christophe Leroy (CS GROUP),
Christian Borntraeger, Sven Schnelle, Eric Snowberg,
Nick Desaulniers, Bill Wendling, Justin Stitt, Andrew Donnellan,
linuxppc-dev, linux-kernel, linux-s390, linux-arch,
linux-integrity, linux-security-module, keyrings, llvm
In-Reply-To: <abb4d186d1ca76c080d5e15bcd9e0019cce3af39.camel@linux.ibm.com>
On Sun, Mar 08, 2026 at 09:01:58PM -0400, Mimi Zohar wrote:
> Thanks Arnd, Nathan. LGTM. Nathan, could you send a patch with a proper patch
> description.
Done, thanks for the input!
https://lore.kernel.org/20260309-integrity-drop-weak-arch-get-secureboot-v1-1-6460d5c4bb89@kernel.org/
Cheers,
Nathan
^ permalink raw reply
* [PATCH RESEND] apparmor: Replace memcpy + NUL termination with kmemdup_nul in do_setattr
From: Thorsten Blum @ 2026-03-09 22:41 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.
Reviewed-by: Serge Hallyn <serge@hallyn.com>
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 c1d42fc72fdb..49aa6ad68838 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -858,12 +858,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;
^ permalink raw reply related
* Re: [PATCH v2 1/2] keys/trusted_keys: clean up debug message logging in the tpm backend
From: Nayna Jain @ 2026-03-09 22:45 UTC (permalink / raw)
To: Srish Srinivasan, linux-integrity, keyrings
Cc: James.Bottomley, jarkko, zohar, stefanb, linux-kernel,
linux-security-module
In-Reply-To: <20260220183426.80446-2-ssrish@linux.ibm.com>
On 2/20/26 1:34 PM, Srish Srinivasan wrote:
> The TPM trusted-keys backend uses a local TPM_DEBUG guard and pr_info()
> for logging debug information.
>
> Replace pr_info() with pr_debug(), and use KERN_DEBUG for print_hex_dump().
> Remove TPM_DEBUG.
>
> No functional change intended.
There is functional change here. This change allows secret and nonce in
the function dump_sess() to be logged to kernel logs when dynamic debug
is enabled. Previously, it was possible only in the debug builds and not
the production builds at runtime. With this change, it is always there
in production build. This can result in possible attack.
Instead of doing this change, I think add a comment to prevent this sort
of change in the future.
Thanks & Regards,
- Nayna
>
> Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
> ---
> security/keys/trusted-keys/trusted_tpm1.c | 40 +++++++----------------
> 1 file changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index c865c97aa1b4..216caef97ffc 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -46,28 +46,25 @@ enum {
> SRK_keytype = 4
> };
>
> -#define TPM_DEBUG 0
> -
> -#if TPM_DEBUG
> static inline void dump_options(struct trusted_key_options *o)
> {
> - pr_info("sealing key type %d\n", o->keytype);
> - pr_info("sealing key handle %0X\n", o->keyhandle);
> - pr_info("pcrlock %d\n", o->pcrlock);
> - pr_info("pcrinfo %d\n", o->pcrinfo_len);
> - print_hex_dump(KERN_INFO, "pcrinfo ", DUMP_PREFIX_NONE,
> + pr_debug("sealing key type %d\n", o->keytype);
> + pr_debug("sealing key handle %0X\n", o->keyhandle);
> + pr_debug("pcrlock %d\n", o->pcrlock);
> + pr_debug("pcrinfo %d\n", o->pcrinfo_len);
> + print_hex_dump(KERN_DEBUG, "pcrinfo ", DUMP_PREFIX_NONE,
> 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
> }
>
> static inline void dump_sess(struct osapsess *s)
> {
> - print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> + print_hex_dump(KERN_DEBUG, "trusted-key: handle ", DUMP_PREFIX_NONE,
> 16, 1, &s->handle, 4, 0);
> - pr_info("secret:\n");
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> + pr_debug("secret:\n");
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE,
> 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
> - pr_info("trusted-key: enonce:\n");
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> + pr_debug("trusted-key: enonce:\n");
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE,
> 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
> }
>
> @@ -75,23 +72,10 @@ static inline void dump_tpm_buf(unsigned char *buf)
> {
> int len;
>
> - pr_info("\ntpm buffer\n");
> + pr_debug("\ntpm buffer\n");
> len = LOAD32(buf, TPM_SIZE_OFFSET);
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> -}
> -#else
> -static inline void dump_options(struct trusted_key_options *o)
> -{
> -}
> -
> -static inline void dump_sess(struct osapsess *s)
> -{
> -}
> -
> -static inline void dump_tpm_buf(unsigned char *buf)
> -{
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> }
> -#endif
>
> static int TSS_rawhmac(unsigned char *digest, const unsigned char *key,
> unsigned int keylen, ...)
^ permalink raw reply
* Re: [PATCH 0/3] Firmware LSM hook
From: Paul Moore @ 2026-03-09 23:10 UTC (permalink / raw)
To: Leon Romanovsky
Cc: James Morris, Serge E. Hallyn, Jason Gunthorpe, Saeed Mahameed,
Itay Avraham, Dave Jiang, Jonathan Cameron, linux-security-module,
linux-kernel, linux-rdma, Chiara Meiohas, Maher Sanalla,
Edward Srouji
In-Reply-To: <20260309193743.GZ12611@unreal>
On Mon, Mar 9, 2026 at 3:37 PM Leon Romanovsky <leon@kernel.org> wrote:
> On Mon, Mar 09, 2026 at 02:32:39PM -0400, Paul Moore wrote:
> > On Mon, Mar 9, 2026 at 7:15 AM Leon Romanovsky <leon@kernel.org> wrote:
> > >
> > > From Chiara:
> > >
> > > This patch set introduces a new LSM hook to validate firmware commands
> > > triggered by userspace before they are submitted to the device. The hook
> > > runs after the command buffer is constructed, right before it is sent
> > > to firmware.
> > >
> > > The goal is to allow a security module to allow or deny a given command
> > > before it is submitted to firmware. BPF LSM can attach to this hook
> > > to implement such policies. This allows fine-grained policies for different
> > > firmware commands.
> > >
> > > In this series, the new hook is called from RDMA uverbs and from the fwctl
> > > subsystem. Both the uverbs and fwctl interfaces use ioctl, so an obvious
> > > candidate would seem to be the file_ioctl hook. However, the userspace
> > > attributes used to build the firmware command buffer are copied from
> > > userspace (copy_from_user()) deep in the driver, depending on various
> > > conditions. As a result, file_ioctl does not have the information required
> > > to make a policy decision.
> > >
> > > This newly introduced hook provides the command buffer together with relevant
> > > metadata (device, command class, and a class-specific device identifier), so
> > > security modules can distinguish between different command classes and devices.
> > >
> > > The hook can be used by other drivers that submit firmware commands via a command
> > > buffer.
> >
> > Hi Leon,
> >
> > At the link below, you'll find guidance on submitting new LSM hooks.
> > Please take a look and let me know if you have any questions.
> >
> > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks
>
> I assume that you are referring to this part:
I'm referring to all of the guidance, but yes, at the very least that
is something that I think we need to see in a future revision of this
patchset.
> * New LSM hooks must demonstrate their usefulness by providing a meaningful
> implementation for at least one in-kernel LSM. The goal is to demonstrate
> the purpose and expected semantics of the hooks. Out of tree kernel code,
> and pass through implementations, such as the BPF LSM, are not eligible
> for LSM hook reference implementations.
>
> The point is that we are not inspecting a kernel call, but the FW mailbox,
> which has very little meaning to the kernel. From the kernel's perspective,
> all relevant checks have already been performed, but the existing capability
> granularity does not allow us to distinguish between FW_CMD1 and FW_CMD2.
It might help if you could phrase this differently, as I'm not
entirely clear on your argument. LSMs are not limited to enforcing
access controls on requests the kernel understands (see the SELinux
userspace object manager concept), and the idea of access controls
with greater granularity than capabilities is one of the main reasons
people look to LSMs for access control (SELinux, AppArmor, Smack,
etc.).
> Here we propose a generic interface that can be applied to all FWCTL
> devices without out-of-tree kernel code at all.
I expected to see a patch implementing some meaningful support for
access controls using these hooks in one of the existing LSMs, I did
not see that in this patchset.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2] docs: security: ipe: fix typos and grammar
From: Fan Wu @ 2026-03-10 4:48 UTC (permalink / raw)
To: Evan Ducas
Cc: wufan, corbet, skhan, rdunlap, bagasdotme, linux-security-module,
linux-doc, linux-kernel
In-Reply-To: <20260308180734.5792-1-evan.j.ducas@gmail.com>
On Sun, Mar 8, 2026 at 11:09 AM Evan Ducas <evan.j.ducas@gmail.com> wrote:
>
> Fix several spelling and grammar mistakes in the IPE
> documentation.
>
> No functional change.
>
> Signed-off-by: Evan Ducas <evan.j.ducas@gmail.com>
> ---
Applied to ipe/next. Thanks.
-Fan
^ permalink raw reply
* Re: [PATCH 0/3] Firmware LSM hook
From: Leon Romanovsky @ 2026-03-10 9:07 UTC (permalink / raw)
To: Paul Moore
Cc: James Morris, Serge E. Hallyn, Jason Gunthorpe, Saeed Mahameed,
Itay Avraham, Dave Jiang, Jonathan Cameron, linux-security-module,
linux-kernel, linux-rdma, Chiara Meiohas, Maher Sanalla,
Edward Srouji
In-Reply-To: <CAHC9VhSRt_QEJKJFBDBySNQCiPpcawd5A76xmoRNtppRKGaCog@mail.gmail.com>
On Mon, Mar 09, 2026 at 07:10:25PM -0400, Paul Moore wrote:
> On Mon, Mar 9, 2026 at 3:37 PM Leon Romanovsky <leon@kernel.org> wrote:
> > On Mon, Mar 09, 2026 at 02:32:39PM -0400, Paul Moore wrote:
> > > On Mon, Mar 9, 2026 at 7:15 AM Leon Romanovsky <leon@kernel.org> wrote:
> > > >
> > > > From Chiara:
> > > >
> > > > This patch set introduces a new LSM hook to validate firmware commands
> > > > triggered by userspace before they are submitted to the device. The hook
> > > > runs after the command buffer is constructed, right before it is sent
> > > > to firmware.
> > > >
> > > > The goal is to allow a security module to allow or deny a given command
> > > > before it is submitted to firmware. BPF LSM can attach to this hook
> > > > to implement such policies. This allows fine-grained policies for different
> > > > firmware commands.
> > > >
> > > > In this series, the new hook is called from RDMA uverbs and from the fwctl
> > > > subsystem. Both the uverbs and fwctl interfaces use ioctl, so an obvious
> > > > candidate would seem to be the file_ioctl hook. However, the userspace
> > > > attributes used to build the firmware command buffer are copied from
> > > > userspace (copy_from_user()) deep in the driver, depending on various
> > > > conditions. As a result, file_ioctl does not have the information required
> > > > to make a policy decision.
> > > >
> > > > This newly introduced hook provides the command buffer together with relevant
> > > > metadata (device, command class, and a class-specific device identifier), so
> > > > security modules can distinguish between different command classes and devices.
> > > >
> > > > The hook can be used by other drivers that submit firmware commands via a command
> > > > buffer.
> > >
> > > Hi Leon,
> > >
> > > At the link below, you'll find guidance on submitting new LSM hooks.
> > > Please take a look and let me know if you have any questions.
> > >
> > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks
> >
> > I assume that you are referring to this part:
>
> I'm referring to all of the guidance, but yes, at the very least that
> is something that I think we need to see in a future revision of this
> patchset.
>
> > * New LSM hooks must demonstrate their usefulness by providing a meaningful
> > implementation for at least one in-kernel LSM. The goal is to demonstrate
> > the purpose and expected semantics of the hooks. Out of tree kernel code,
> > and pass through implementations, such as the BPF LSM, are not eligible
> > for LSM hook reference implementations.
> >
> > The point is that we are not inspecting a kernel call, but the FW mailbox,
> > which has very little meaning to the kernel. From the kernel's perspective,
> > all relevant checks have already been performed, but the existing capability
> > granularity does not allow us to distinguish between FW_CMD1 and FW_CMD2.
>
> It might help if you could phrase this differently, as I'm not
> entirely clear on your argument. LSMs are not limited to enforcing
> access controls on requests the kernel understands (see the SELinux
> userspace object manager concept), and the idea of access controls
> with greater granularity than capabilities is one of the main reasons
> people look to LSMs for access control (SELinux, AppArmor, Smack,
> etc.).
I should note that my understanding of LSM is limited, so some parts of my
answers may be inaccurate.
What I am referring to is a different level of granularity — specifically,
the internals of the firmware commands. In the proposed approach, BPF
programs would make decisions based on data passed through the mailbox.
That mailbox format varies across vendors, and may even differ between
firmware versions from the same vendor.
>
> > Here we propose a generic interface that can be applied to all FWCTL
> > devices without out-of-tree kernel code at all.
>
> I expected to see a patch implementing some meaningful support for
> access controls using these hooks in one of the existing LSMs, I did
> not see that in this patchset.
In some cases, the mailbox is forwarded from user space unchanged, but
in others the kernel modifies it before submitting it to the FW.
For example, at line 1140 we update the UID field, which indicates the
process to which the request belongs. This field is managed by the
kernel to ensure that user processes cannot access FW internals of other
processes.
1108 static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OTHER)(
1109 struct uverbs_attr_bundle *attrs)
1110 {
1111 struct mlx5_ib_ucontext *c;
1112 struct mlx5_ib_dev *dev;
1113 void *cmd_in = uverbs_attr_get_alloced_ptr(
1114 attrs, MLX5_IB_ATTR_DEVX_OTHER_CMD_IN);
<...>
1121 int uid;
<...>
1128 uid = devx_get_uid(c, cmd_in);
1129 if (uid < 0)
1130 return uid;
<...>
1140 MLX5_SET(general_obj_in_cmd_hdr, cmd_in, uid, uid);
1141 err = security_fw_validate_cmd(cmd_in, cmd_in_len, &dev->ib_dev.dev,
1142 FW_CMD_CLASS_UVERBS, RDMA_DRIVER_MLX5);
1143 if (err)
1144 return err;
1145
1146 err = mlx5_cmd_do(dev->mdev, cmd_in, cmd_in_len, cmd_out, cmd_out_len);
Could you point me to the LSM that would be best suited for performing
checks of this kind?
Thanks
>
> --
> paul-moore.com
^ permalink raw reply
* Re: [v2,net-next,07/15] udp: Remove partial csum code in RX.
From: Paolo Abeni @ 2026-03-10 10:25 UTC (permalink / raw)
To: kuniyu
Cc: willemb, serge, linux-security-module, netdev, davem, edumazet,
kuba, pabeni, dsahern, jmorris, casey, paul, kuni1840, fw, horms,
willemdebruijn.kernel
In-Reply-To: <20260305215013.2984628-8-kuniyu@google.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
udp: Remove partial csum code in RX.
This commit removes UDP-Lite specific partial checksum handling from UDP
receive paths, including removal of UDP_SKB_CB fields, simplification of
checksum initialization functions, and elimination of UDP-Lite guards.
Link: https://lore.kernel.org/netdev/20260305215013.2984628-8-kuniyu@google.com/
> diff --git a/include/net/udp.h b/include/net/udp.h
> --- a/include/net/udp.h
> +++ b/include/net/udp.h
[ ... ]
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
[ ... ]
> @@ -2703,14 +2647,15 @@ static int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
> if (ulen > skb->len)
> goto short_packet;
>
> - if (proto == IPPROTO_UDP) {
> - /* UDP validates ulen. */
> - if (ulen < sizeof(*uh) || pskb_trim_rcsum(skb, ulen))
> + /* UDP validates ulen. */
> + if (ulen < sizeof(*uh)) {
> + if (pskb_trim_rcsum(skb, ulen))
> goto short_packet;
> +
> uh = udp_hdr(skb);
> }
>
> - if (udp4_csum_init(skb, uh, proto))
> + if (udp4_csum_init(skb, uh))
> goto csum_error;
>
Does this refactoring introduce two bugs?
The old code checked both conditions with short-circuit OR:
if (ulen < sizeof(*uh) || pskb_trim_rcsum(skb, ulen))
goto short_packet;
This correctly (1) rejected packets where ulen < 8, and (2) trimmed the
SKB to the declared UDP length when ulen < skb->len.
The new code changes the logic structure:
if (ulen < sizeof(*uh)) {
if (pskb_trim_rcsum(skb, ulen))
goto short_packet;
uh = udp_hdr(skb);
}
First potential bug: When sizeof(*uh) <= ulen < skb->len, the entire block
is skipped. This means pskb_trim_rcsum() is never called, so the SKB
retains trailing data beyond the declared UDP length. Won't this cause
checksum calculations to include extraneous bytes, leading to valid packets
being incorrectly rejected?
This scenario occurs when UDP length < IP payload length, which can happen
with malformed or crafted packets.
Second potential bug: When ulen < sizeof(*uh), the old code would
immediately goto short_packet via the || short-circuit. The new code enters
the block and tries to trim the SKB to a sub-header-size length. If
pskb_trim_rcsum() succeeds, processing continues with skb->len <
sizeof(struct udphdr). Is this safe?
Looking at the IPv6 counterpart __udp6_lib_rcv(), it handles this
differently:
if (ulen < sizeof(*uh))
goto short_packet;
if (ulen < skb->len) {
if (pskb_trim_rcsum(skb, ulen))
goto short_packet;
saddr = &ipv6_hdr(skb)->saddr;
daddr = &ipv6_hdr(skb)->daddr;
uh = udp_hdr(skb);
}
Should the IPv4 code follow the same pattern, or should it preserve the
original short-circuit logic:
if (ulen < sizeof(*uh) || pskb_trim_rcsum(skb, ulen))
goto short_packet;
uh = udp_hdr(skb);
^ permalink raw reply
* Re: [PATCH v2 00/27] Allow inlining C helpers into Rust when using LTO
From: Miguel Ojeda @ 2026-03-10 10:56 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: clk: add __rust_helper to helpers
> rust: jump_label: add __rust_helper to helpers
Applied these to `rust-next` -- thanks everyone!
With these, the series is complete.
Cheers,
Miguel
^ permalink raw reply
* [PATCH 0/2] vfs: follow-on fixes for i_ino widening
From: Jeff Layton @ 2026-03-10 11:43 UTC (permalink / raw)
To: Christian Brauner, Ryusuke Konishi, Viacheslav Dubeyko,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-nilfs, linux-kernel, linux-integrity, linux-security-module,
Jeff Layton, kernel test robot
Just some patches to fix follow-on issues reported after the
inode->i_ino widening series. Christian, please toss these onto
vfs-7.1.kino, assuming they pass review.
Thanks,
Jeff
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Jeff Layton (2):
nilfs2: fix 64-bit division operations in nilfs_bmap_find_target_in_group()
EVM: add comment describing why ino field is still unsigned long
fs/nilfs2/bmap.c | 9 ++++++---
security/integrity/evm/evm_crypto.c | 6 ++++++
2 files changed, 12 insertions(+), 3 deletions(-)
---
base-commit: 9840bb66e7e5dffd72b03201318f154a10b06b4a
change-id: 20260310-iino-u64-424fa570d850
Best regards,
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* [PATCH 1/2] nilfs2: fix 64-bit division operations in nilfs_bmap_find_target_in_group()
From: Jeff Layton @ 2026-03-10 11:43 UTC (permalink / raw)
To: Christian Brauner, Ryusuke Konishi, Viacheslav Dubeyko,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-nilfs, linux-kernel, linux-integrity, linux-security-module,
Jeff Layton, kernel test robot
In-Reply-To: <20260310-iino-u64-v1-0-18422a053b04@kernel.org>
With the change to make inode->i_ino a u64, the build started failing on
32-bit ARM with:
ERROR: modpost: "__aeabi_uldivmod" [fs/nilfs2/nilfs2.ko] undefined!
Fix this by using the 64-bit division interfaces in
nilfs_bmap_find_target_in_group().
Fixes: 998a59d371c2 ("treewide: fix missed i_ino format specifier conversions")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603100602.KPxiClIO-lkp@intel.com/
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/nilfs2/bmap.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/nilfs2/bmap.c b/fs/nilfs2/bmap.c
index 824f2bd91c167965ec3a660202b6e6c5f1fe007e..4ce9a93149a5af13bc215cc1877a757e2c6cf49b 100644
--- a/fs/nilfs2/bmap.c
+++ b/fs/nilfs2/bmap.c
@@ -455,11 +455,14 @@ __u64 nilfs_bmap_find_target_in_group(const struct nilfs_bmap *bmap)
{
struct inode *dat = nilfs_bmap_get_dat(bmap);
unsigned long entries_per_group = nilfs_palloc_entries_per_group(dat);
- unsigned long group = bmap->b_inode->i_ino / entries_per_group;
+ unsigned long group;
+ u32 rem;
+
+ group = div_u64(bmap->b_inode->i_ino, entries_per_group);
+ div_u64_rem(bmap->b_inode->i_ino, NILFS_BMAP_GROUP_DIV, &rem);
return group * entries_per_group +
- (bmap->b_inode->i_ino % NILFS_BMAP_GROUP_DIV) *
- (entries_per_group / NILFS_BMAP_GROUP_DIV);
+ rem * (entries_per_group / NILFS_BMAP_GROUP_DIV);
}
static struct lock_class_key nilfs_bmap_dat_lock_key;
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] EVM: add comment describing why ino field is still unsigned long
From: Jeff Layton @ 2026-03-10 11:43 UTC (permalink / raw)
To: Christian Brauner, Ryusuke Konishi, Viacheslav Dubeyko,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-nilfs, linux-kernel, linux-integrity, linux-security-module,
Jeff Layton
In-Reply-To: <20260310-iino-u64-v1-0-18422a053b04@kernel.org>
Mimi pointed out that we didn't widen the inode number field in struct
h_misc alongside the inode->i_ino widening. While we could make an
equivalent change there, that would force EVM remeasurement on all
32-bit hosts.
Instead, leave the field as an unsigned long. This should have no effect
on 64-bit hosts, and allow things to continue working on 32-bit hosts in
the cases where the i_ino fits in 32-bits.
Add a comment explaining why it's being left as unsigned long.
Cc: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
security/integrity/evm/evm_crypto.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
index c0ca4eedb0fe5d5c30f45f515a4bc90248ec64ea..3445f4c2097f7e8af61de6299b721fc4a1d8afb4 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -144,6 +144,12 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
char type, char *digest)
{
struct h_misc {
+ /*
+ * Although inode->i_ino is now u64, this field remains
+ * unsigned long to allow existing hashes from 32-bit hosts
+ * to continue working when i_ino hasn't changed and fitsxi
+ * in a u32.
+ */
unsigned long ino;
__u32 generation;
uid_t uid;
--
2.53.0
^ permalink raw reply related
* [PATCH 05/61] smb: Prefer IS_ERR_OR_NULL over manual NULl check
From: Philipp Hahn @ 2026-03-10 11:48 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Steve French, Paulo Alcantara, Ronnie Sahlberg, Shyam Prasad N,
Tom Talpey, Bharath SM
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
check.
Change generated with coccinelle.
To: Steve French <sfrench@samba.org>
To: Paulo Alcantara <pc@manguebit.org>
To: Ronnie Sahlberg <ronniesahlberg@gmail.com>
To: Shyam Prasad N <sprasad@microsoft.com>
To: Tom Talpey <tom@talpey.com>
To: Bharath SM <bharathsm@microsoft.com>
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
fs/smb/client/cifsglob.h | 2 +-
fs/smb/client/connect.c | 2 +-
fs/smb/client/readdir.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/smb/client/cifsglob.h b/fs/smb/client/cifsglob.h
index 6f9b6c72962b09260542b711d4c64e7dc42c7845..fb731b2609465ebe50742936b458aba210ecbd4a 100644
--- a/fs/smb/client/cifsglob.h
+++ b/fs/smb/client/cifsglob.h
@@ -1336,7 +1336,7 @@ void cifs_put_tlink(struct tcon_link *tlink);
static inline struct tcon_link *
cifs_get_tlink(struct tcon_link *tlink)
{
- if (tlink && !IS_ERR(tlink))
+ if (!IS_ERR_OR_NULL(tlink))
atomic_inc(&tlink->tl_count);
return tlink;
}
diff --git a/fs/smb/client/connect.c b/fs/smb/client/connect.c
index 3bad2c5c523dbd1d4b1ab253567984612be0f348..aa12d327894b270b59ea30be0e6d77b4188fc98f 100644
--- a/fs/smb/client/connect.c
+++ b/fs/smb/client/connect.c
@@ -2895,7 +2895,7 @@ cifs_get_tcon(struct cifs_ses *ses, struct smb3_fs_context *ctx)
void
cifs_put_tlink(struct tcon_link *tlink)
{
- if (!tlink || IS_ERR(tlink))
+ if (IS_ERR_OR_NULL(tlink))
return;
if (!atomic_dec_and_test(&tlink->tl_count) ||
diff --git a/fs/smb/client/readdir.c b/fs/smb/client/readdir.c
index be22bbc4a65a03ec64b87d8505d1496279f22efc..3e9260cca196ea8ab17aad82c4824ec5e468e2e7 100644
--- a/fs/smb/client/readdir.c
+++ b/fs/smb/client/readdir.c
@@ -165,7 +165,7 @@ cifs_prime_dcache(struct dentry *parent, struct qstr *name,
inode = ERR_PTR(-ENOMEM);
alias = d_splice_alias(inode, dentry);
d_lookup_done(dentry);
- if (alias && !IS_ERR(alias))
+ if (!IS_ERR_OR_NULL(alias))
dput(alias);
}
dput(dentry);
--
2.43.0
^ permalink raw reply related
* [PATCH 07/61] erofs: Prefer IS_ERR_OR_NULL over manual NULL check
From: Philipp Hahn @ 2026-03-10 11:48 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu, Sandeep Dhavale, Hongbo Li,
Chunhai Guo
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
check.
Change generated with coccinelle.
To: Gao Xiang <xiang@kernel.org>
To: Chao Yu <chao@kernel.org>
To: Yue Hu <zbestahu@gmail.com>
To: Jeffle Xu <jefflexu@linux.alibaba.com>
To: Sandeep Dhavale <dhavale@google.com>
To: Hongbo Li <lihongbo22@huawei.com>
To: Chunhai Guo <guochunhai@vivo.com>
Cc: linux-erofs@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
fs/erofs/zdata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
index 3977e42b9516861bf3d59c072b6b8aaa6898dd8a..88c293ab2b1ef7962c6f5c0aa82639859e41b8e2 100644
--- a/fs/erofs/zdata.c
+++ b/fs/erofs/zdata.c
@@ -1227,7 +1227,7 @@ static int z_erofs_parse_in_bvecs(struct z_erofs_backend *be, bool *overlapped)
struct page *page = bvec->page;
/* compressed data ought to be valid when decompressing */
- if (IS_ERR(page) || !page) {
+ if (IS_ERR_OR_NULL(page)) {
bvec->page = NULL; /* clear the failure reason */
err = page ? PTR_ERR(page) : -EIO;
continue;
--
2.43.0
^ permalink raw reply related
* [PATCH 03/61] ceph: Prefer IS_ERR_OR_NULL over manual NULL check
From: Philipp Hahn @ 2026-03-10 11:48 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Ilya Dryomov, Alex Markuze, Viacheslav Dubeyko
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
check.
Change generated with coccinelle.
To: Ilya Dryomov <idryomov@gmail.com>
To: Alex Markuze <amarkuze@redhat.com>
To: Viacheslav Dubeyko <slava@dubeyko.com>
Cc: ceph-devel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
fs/ceph/dir.c | 2 +-
fs/ceph/snap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
index 86d7aa594ea99335af3e91a95c0a418fdc1b8a8a..934250748ae4fd4c148fd27bdf91175047c2877d 100644
--- a/fs/ceph/dir.c
+++ b/fs/ceph/dir.c
@@ -889,7 +889,7 @@ int ceph_handle_notrace_create(struct inode *dir, struct dentry *dentry)
{
struct dentry *result = ceph_lookup(dir, dentry, 0);
- if (result && !IS_ERR(result)) {
+ if (!IS_ERR_OR_NULL(result)) {
/*
* We created the item, then did a lookup, and found
* it was already linked to another inode we already
diff --git a/fs/ceph/snap.c b/fs/ceph/snap.c
index 52b4c2684f922bfed39550311e793bfe3622cd26..528ad581be160713f91416115659e2dc6f259576 100644
--- a/fs/ceph/snap.c
+++ b/fs/ceph/snap.c
@@ -902,7 +902,7 @@ int ceph_update_snap_trace(struct ceph_mds_client *mdsc,
bad:
err = -EIO;
fail:
- if (realm && !IS_ERR(realm))
+ if (!IS_ERR_OR_NULL(realm))
ceph_put_snap_realm(mdsc, realm);
if (first_realm)
ceph_put_snap_realm(mdsc, first_realm);
--
2.43.0
^ permalink raw reply related
* [PATCH 13/61] squashfs: Prefer IS_ERR_OR_NULL over manual NULL check
From: Philipp Hahn @ 2026-03-10 11:48 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Phillip Lougher
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
check.
Change generated with coccinelle.
To: Phillip Lougher <phillip@squashfs.org.uk>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
fs/squashfs/cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/squashfs/cache.c b/fs/squashfs/cache.c
index 67abd4dff222235e75d8c2b10d5e9b811d6e38d8..8888cc02966e2e33210c872c733205d4c581ecc9 100644
--- a/fs/squashfs/cache.c
+++ b/fs/squashfs/cache.c
@@ -198,7 +198,7 @@ void squashfs_cache_delete(struct squashfs_cache *cache)
{
int i, j;
- if (IS_ERR(cache) || cache == NULL)
+ if (IS_ERR_OR_NULL(cache))
return;
for (i = 0; i < cache->entries; i++) {
--
2.43.0
^ permalink raw reply related
* [PATCH 02/61] btrfs: Prefer IS_ERR_OR_NULL over manual NULL check
From: Philipp Hahn @ 2026-03-10 11:48 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Chris Mason, David Sterba
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
check.
IS_ERR_OR_NULL() already uses likely(!ptr) internally. checkpatch does
not like nesting it:
> WARNING: nested (un)?likely() calls, IS_ERR_OR_NULL already uses
> unlikely() internally
Remove the explicit use of likely().
Change generated with coccinelle.
To: Chris Mason <clm@fb.com>
To: David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
fs/btrfs/inode.c | 2 +-
fs/btrfs/transaction.c | 2 +-
fs/btrfs/tree-log.c | 2 +-
fs/btrfs/uuid-tree.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index a11fcc9e9f502c559148cf33679014fb83b0d3b0..7c26a0bf56bf7309e2ce8256854d760b2d64b16a 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4683,7 +4683,7 @@ static noinline int may_destroy_subvol(struct btrfs_root *root)
dir_id = btrfs_super_root_dir(fs_info->super_copy);
di = btrfs_lookup_dir_item(NULL, fs_info->tree_root, path,
dir_id, &name, 0);
- if (di && !IS_ERR(di)) {
+ if (!IS_ERR_OR_NULL(di)) {
btrfs_dir_item_key_to_cpu(path->nodes[0], di, &key);
if (key.objectid == btrfs_root_id(root)) {
ret = -EPERM;
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 7ef8c9b7dfc17a5133b6d2dc134e288975ed98d1..40b83037725033d3178dc3fc2c1e347ad2c597f7 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1737,7 +1737,7 @@ static noinline int create_pending_snapshot(struct btrfs_trans_handle *trans,
dir_item = btrfs_lookup_dir_item(NULL, parent_root, path,
btrfs_ino(parent_inode),
&fname.disk_name, 0);
- if (unlikely(dir_item != NULL && !IS_ERR(dir_item))) {
+ if (!IS_ERR_OR_NULL(dir_item)) {
pending->error = -EEXIST;
goto dir_item_existed;
} else if (IS_ERR(dir_item)) {
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 780a06d592409b05fb42dc8079b019d23fe0cdfa..2e07ae393cf9d16f562047dd4cbfd7b4b9f2952e 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -5750,7 +5750,7 @@ static int btrfs_check_ref_name_override(struct extent_buffer *eb,
name_str.len = this_name_len;
di = btrfs_lookup_dir_item(NULL, inode->root, search_path,
parent, &name_str, 0);
- if (di && !IS_ERR(di)) {
+ if (!IS_ERR_OR_NULL(di)) {
struct btrfs_key di_key;
btrfs_dir_item_key_to_cpu(search_path->nodes[0],
diff --git a/fs/btrfs/uuid-tree.c b/fs/btrfs/uuid-tree.c
index f24c14b9bb2fd7420b06263a5a0c4b889a859bc6..c497b287f3418933e532903b326b969416ae22cb 100644
--- a/fs/btrfs/uuid-tree.c
+++ b/fs/btrfs/uuid-tree.c
@@ -478,7 +478,7 @@ int btrfs_uuid_scan_kthread(void *data)
out:
btrfs_free_path(path);
- if (trans && !IS_ERR(trans))
+ if (!IS_ERR_OR_NULL(trans))
btrfs_end_transaction(trans);
if (ret)
btrfs_warn(fs_info, "btrfs_uuid_scan_kthread failed %d", ret);
--
2.43.0
^ permalink raw reply related
* [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
From: Philipp Hahn @ 2026-03-10 11:48 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Julia Lawall, Nicolas Palix
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
Find and convert uses of IS_ERR() plus NULL check to IS_ERR_OR_NULL().
There are several cases where `!ptr && WARN_ON[_ONCE](IS_ERR(ptr))` is
used:
- arch/x86/kernel/callthunks.c:215 WARN_ON_ONCE
- drivers/clk/clk.c:4561 WARN_ON_ONCE
- drivers/interconnect/core.c:793 WARN_ON
- drivers/reset/core.c:718 WARN_ON
The change is not 100% semantical equivalent as the warning will now
also happen when the pointer is NULL.
To: Julia Lawall <Julia.Lawall@inria.fr>
To: Nicolas Palix <nicolas.palix@imag.fr>
Cc: cocci@inria.fr
Cc: linux-kernel@vger.kernel.org
---
drivers/clocksource/mips-gic-timer.c:283 looks suspicious: ret != clk,
but Daniel Lezcano verified it as cottect.
There are some cases where the checks are part of a larger expression:
- mm/kmemleak.c:1095
- mm/kmemleak.c:1155
- mm/kmemleak.c:1173
- mm/kmemleak.c:1290
- mm/kmemleak.c:1328
- mm/kmemleak.c:1241
- mm/kmemleak.c:1310
- mm/kmemleak.c:1258
- net/netlink/af_netlink.c:2670
Thanks to Julia Lawall for the help to also handle them.
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
scripts/coccinelle/api/is_err_or_null.cocci | 125 ++++++++++++++++++++++++++++
1 file changed, 125 insertions(+)
diff --git a/scripts/coccinelle/api/is_err_or_null.cocci b/scripts/coccinelle/api/is_err_or_null.cocci
new file mode 100644
index 0000000000000000000000000000000000000000..7a430eadccd9f9f28b1711d67dd87a817a45bd52
--- /dev/null
+++ b/scripts/coccinelle/api/is_err_or_null.cocci
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0-only
+///
+/// Use IF_ERR_OR_NULL() instead of IS_ERR() plus a check for (not) NULL
+///
+// Copyright: (C) 2026 Philipp Hahn, FRITZ! Technology GmbH.
+// Confidence: High
+// Options: --no-includes --include-headers
+// Keywords: IS_ERR, IS_ERR_OR_NULL
+
+virtual patch
+virtual report
+virtual org
+
+@p1 depends on patch@
+expression E;
+@@
+(
+- E != NULL && !IS_ERR(E)
++ !IS_ERR_OR_NULL(E)
+|
+- E == NULL || IS_ERR(E)
++ IS_ERR_OR_NULL(E)
+|
+- !IS_ERR(E) && E != NULL
++ !IS_ERR_OR_NULL(E)
+|
+- IS_ERR(E) || E == NULL
++ IS_ERR_OR_NULL(E)
+)
+
+@p2 depends on patch@
+expression E;
+@@
+(
+- E == NULL || WARN_ON(IS_ERR(E))
++ WARN_ON(IS_ERR_OR_NULL(E))
+|
+- E == NULL || WARN_ON_ONCE(IS_ERR(E))
++ WARN_ON_ONCE(IS_ERR_OR_NULL(E))
+)
+
+@p3 depends on patch@
+expression E,e1;
+@@
+(
+- e1 && E != NULL && !IS_ERR(E)
++ e1 && !IS_ERR_OR_NULL(E)
+|
+- e1 || E == NULL || IS_ERR(E)
++ e1 || IS_ERR_OR_NULL(E)
+|
+- e1 && !IS_ERR(E) && E != NULL
++ e1 && !IS_ERR_OR_NULL(E)
+|
+- e1 || IS_ERR(E) || E == NULL
++ e1 || IS_ERR_OR_NULL(E)
+)
+
+@r1 depends on report || org@
+expression E;
+position p;
+@@
+(
+ E != NULL && ... && !IS_ERR@p(E)
+|
+ E == NULL || ... || IS_ERR@p(E)
+|
+ !IS_ERR@p(E) && ... && E != NULL
+|
+ IS_ERR@p(E) || ... || E == NULL
+)
+
+@script:python depends on report@
+p << r1.p;
+@@
+coccilib.report.print_report(p[0], "opportunity for IS_ERR_OR_NULL()")
+
+@script:python depends on org@
+p << r1.p;
+@@
+coccilib.org.print_todo(p[0], "opportunity for IS_ERR_OR_NULL()")
+
+@p4 depends on patch@
+identifier I;
+expression E;
+@@
+(
+- (I = E) != NULL && !IS_ERR(I)
++ !IS_ERR_OR_NULL((I = E))
+|
+- (I = E) == NULL || IS_ERR(I)
++ IS_ERR_OR_NULL((I = E))
+)
+
+@r2 depends on report || org@
+identifier I;
+expression E;
+position p;
+@@
+(
+* (I = E) != NULL && ... && !IS_ERR@p(I)
+|
+* (I = E) == NULL || ... || IS_ERR@p(I)
+)
+
+@script:python depends on report@
+p << r2.p;
+@@
+coccilib.report.print_report(p[0], "opportunity for IS_ERR_OR_NULL()")
+
+@script:python depends on org@
+p << r2.p;
+@@
+coccilib.org.print_todo(p[0], "opportunity for IS_ERR_OR_NULL()")
+
+@p5 depends on patch disable unlikely @
+expression E;
+@@
+-\( likely \| unlikely \)(
+(
+ IS_ERR_OR_NULL(E)
+|
+ !IS_ERR_OR_NULL(E)
+)
+-)
--
2.43.0
^ permalink raw reply related
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