* Re: [PATCH v4 3/3] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Sudeep Holla @ 2026-06-02 9:57 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Yeoreum Yun, Sudeep Holla, linux-security-module, linux-kernel,
linux-integrity, paul, zohar, roberto.sassu, noodles, jmorris,
serge, dmitry.kasatkin, eric.snowberg, jgg
In-Reply-To: <ah428rLnpoIersnQ@kernel.org>
On Tue, Jun 02, 2026 at 04:50:42AM +0300, Jarkko Sakkinen wrote:
> On Mon, Jun 01, 2026 at 09:54:08AM +0100, Sudeep Holla wrote:
> > On Mon, Jun 01, 2026 at 08:17:13AM +0100, Yeoreum Yun wrote:
> > > Hi Jarkko,
> > >
> > > Sorry for late answer.
> > >
> > > > On Mon, May 25, 2026 at 08:54:04AM +0100, Yeoreum Yun wrote:
> > > > > commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
> > > > > probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
> > > > >
> > > > > However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
> > > > > initialises IMA at the late_initcall_sync level, so this change is no
> > > > > longer required.
> > > > >
> > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > ---
> > > > > drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
> > > > > 1 file changed, 3 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> > > > > index 99f1c1e5644b..025c4d4b17ca 100644
> > > > > --- a/drivers/char/tpm/tpm_crb_ffa.c
> > > > > +++ b/drivers/char/tpm/tpm_crb_ffa.c
> > > > > @@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> > > > > */
> > > > > int tpm_crb_ffa_init(void)
> > > > > {
> > > > > - int ret = 0;
> > > > > -
> > > > > - if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> > > > > - ret = ffa_register(&tpm_crb_ffa_driver);
> > > > > - if (ret) {
> > > > > - tpm_crb_ffa = ERR_PTR(-ENODEV);
> > > > > - return ret;
> > > > > - }
> > > > > - }
> > > > > -
> > > > > if (!tpm_crb_ffa)
> > > > > - ret = -ENOENT;
> > > > > + return -ENOENT;
> > > > >
> > > > > if (IS_ERR_VALUE(tpm_crb_ffa))
> > > > > - ret = -ENODEV;
> > > > > + return -ENODEV;
> > > > >
> > > > > - return ret;
> > > > > + return 0;
> > > > > }
> > > > > EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
> > > > >
> > > > > @@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
> > > > > .id_table = tpm_crb_ffa_device_id,
> > > > > };
> > > > >
> > > > > -#ifdef MODULE
> > > > > module_ffa_driver(tpm_crb_ffa_driver);
> > > > > -#endif
> > > > >
> > > > > MODULE_AUTHOR("Arm");
> > > > > MODULE_DESCRIPTION("TPM CRB FFA driver");
> > > > > --
> > > > > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
> > > > >
> > > >
> > > > How we would sync up this patch? Through which tree etc.
> > >
> > > IMHO, the IMA relevant thing would be into IMA tree,
> > > However I think this patch would be much easier to sync into Sudeep's
> > > FF-A tree where ff-a initilisation is reverted to device_initcall
> > > unless you're uncomfortable.
> > >
> > > For this, It might be better to split this patch from this series
> > > since by above and defer probe of ff-a would make a register failure
> > > of registering tpm_crb_ffa driver which is built-in.
> > >
> > > @Sudeep what do you think?
> > >
> >
> > IIRC, there is/was no dependency between these and FF-A patches that are
> > queued in terms of build. I agree there may be dependency to get all the
> > functionality but we can resort to linux-next for that. FF-A is not enabled
> > in the defconfig, so anyone working on FF-A + TPM must enable then and can
> > rely on -next IMHO.
> >
> > That said, I have already sent PR for FF-A to SoC team and it is already
> > queued for v7.2. I don't have any other plans unless they are fixes.
>
> Works for me.
>
Sorry if I was not clear. I haven't included any TPM patches in this series
as part of my FF-A pull request queued for v7.2. So I was asking to route this
via your tree.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] KEYS: Use acquire when reading state in keyring search
From: Gui-Dong Han @ 2026-06-02 9:42 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: dhowells, keyrings, ebiggers, linux-security-module, linux-kernel,
baijiaju1990
In-Reply-To: <aho3CYdv8lQd2s85@kernel.org>
On Sat, May 30, 2026 at 9:02 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Fri, May 29, 2026 at 11:34:06AM +0800, Gui-Dong Han wrote:
> > The negative-key race fix added release/acquire ordering for key use.
> >
> > Publish payload before state; read state before payload.
> >
> > keyring_search_iterator() still uses READ_ONCE() before match callbacks.
> > An asymmetric match callback calls asymmetric_key_ids(), which reads
> > key->payload.data[asym_key_ids].
> >
> > Use key_read_state() there to complete that ordering.
>
> OK, so... I'm having a bit trouble understanding the exact concurrency
> scenario you're trying to describe despite I think I get the fix itself
> i.e. it is not pairing with mark_key_instantiated?
Yes, it is intended to pair with mark_key_instantiated().
>
> I'm a bit puzzled too why this was not done already in the original
> commit despite introducing all the primitives.
The original commit added the right primitives, but this site was easy to
miss because the payload access is hidden behind ctx->match_data.cmp().
For example, the asymmetric match callbacks call asymmetric_key_ids(),
which reads key->payload.data[asym_key_ids].
I also checked the two pre-existing issues reported by Sashiko [1].
The uninitialized-read case does not look possible from the code, but the
cached-error issue is real and was dynamically reproduced. I can send a
separate patch for that if useful.
Thanks.
[1] https://sashiko.dev/#/patchset/20260529033406.20673-1-hanguidong02%40gmail.com
>
> >
> > Fixes: 363b02dab09b ("KEYS: Fix race between updating and finding a negative key")
> > Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
> > ---
> > Found by auditing READ_ONCE() used for synchronization.
> > A similar fix can be found in 8df672bfe3ec.
> > ---
> > security/keys/keyring.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/security/keys/keyring.c b/security/keys/keyring.c
> > index b39038f7dd31..243fb1636f10 100644
> > --- a/security/keys/keyring.c
> > +++ b/security/keys/keyring.c
> > @@ -576,7 +576,7 @@ static int keyring_search_iterator(const void *object, void *iterator_data)
> > struct keyring_search_context *ctx = iterator_data;
> > const struct key *key = keyring_ptr_to_key(object);
> > unsigned long kflags = READ_ONCE(key->flags);
> > - short state = READ_ONCE(key->state);
> > + short state = key_read_state(key);
> >
> > kenter("{%d}", key->serial);
> >
> > --
> > 2.34.1
> >
>
> BR, Jarkko
^ permalink raw reply
* Re: [PATCH v4 0/2] Delete task_euid()
From: Alice Ryhl @ 2026-06-02 6:15 UTC (permalink / raw)
To: Paul Moore
Cc: Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman, Shuah Khan,
Alex Shi, Yanteng Si, Dongliang Mu, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Jann Horn, linux-security-module,
linux-doc, linux-kernel, rust-for-linux
In-Reply-To: <CAHC9VhR5Ca+WyP2OiNGtL1SqHn0SwLe=M9SB8D2bxtdS52quhg@mail.gmail.com>
On Mon, Jun 01, 2026 at 07:13:37PM -0400, Paul Moore wrote:
> On Fri, May 29, 2026 at 5:33 AM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > The task_euid() method is a very weird method, and Binder was the only
> > user. As of commit 65b672152289 ("binder: use current_euid() for
> > transaction sender identity") Binder doesn't use task_euid() anymore,
> > so we can delete this method.
>
> Given the problems from last time, it seems like it might be prudent
> to let the commit have some time to "breathe" in a proper release, I'd
> suggest merging this not for the upcoming v7.2 merge window but
> instead waiting for v7.3.
Sure, that makes sense. I'll resend after the merge window.
> > My suggestion would be to merge this through the LSM tree.
>
> That's fine with me. I'd also suggest updating the commit description
> in patch 1/2 to indicate that binder is no longer using task_euid();
> it currently reads like it is still being used.
I guess this occurred because when patch 1 was written, it really *was*
still being used. Perhaps we could pick up only patch 1 now since even
if we run into problems and Binder has to go back to using task_euid(),
clarifying the docs is still useful.
Alice
^ permalink raw reply
* Re: [PATCH 01/11] hornet: fix TOCTOU in signed program verification
From: Fan Wu @ 2026-06-02 4:01 UTC (permalink / raw)
To: Paul Moore
Cc: Fan Wu, Blaise Boscaccy, Jonathan Corbet, Shuah Khan,
James Morris, Serge E. Hallyn, Eric Biggers, James.Bottomley,
linux-security-module
In-Reply-To: <CAHC9VhSt1_XmKfO7SA_5qiUUpq5RWa98yACHSwh9KMMGQTJjbg@mail.gmail.com>
On Mon, Jun 1, 2026 at 8:26 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Fri, May 29, 2026 at 9:11 PM Fan Wu <wufan@kernel.org> wrote:
> > On Wed, May 27, 2026 at 8:09 PM Blaise Boscaccy
> > <bboscaccy@linux.microsoft.com> wrote:
> > >
> > > The signature verification path was vulnerable to a time-of-check vs
> > > time-of-use race at both the program load and program run hook sites:
> > > between the moment a map's contents were hashed for signature
> > > verification and the moment the program run hook re-verified them, an
> > > attacker with sufficient privileges could swap or mutate the map
> > > contents.
> > >
> > > Close the race by snapshotting the map hashes during program load,
> > > attaching them to the program, and re-verifying them from the
> > > security_bpf_prog hook against prog->aux->used_maps. Because used_maps
> > > is the same map set the verifier and runtime resolve against, there is
> > > no longer a window in which the verified set and the executed set can
> > > diverge.
> > >
> > > Since we are no longer targeting the fd_array passed in, drop the map
> > > index data entirely and check for whether or not the set of requested
> > > map hashes is a subset of prog->aux->used_maps.
> > >
> > > Reported-by: Eric Biggers <ebiggers@kernel.org>
> > > Signed-off-by: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
> > > ---
...
> > similar above, they should be removed for the header and for the ipe policy.
>
> I would prefer to see LSM_INT_VERDICT_FAULT preserved as I think it is
> good to have a verdict indicating a general error in the integrity
> verification code, but I do agree with Fan that removing
> VERDICT_UNEXPECTED is probably a good thing to do.
>
> If Fan is insistent on removal of VERDICT_FAULT from the IPE code
> that's fine, just leave it in the LSM header.
>
> Can you get a patch out for this ASAP Blaise?
>
> --
> paul-moore.com
I'm good with keeping LSM_INT_VERDICT_FAULT.
-Fan
^ permalink raw reply
* Re: [PATCH 02/11] hornet: invert map set check logic
From: Paul Moore @ 2026-06-02 3:36 UTC (permalink / raw)
To: Fan Wu
Cc: Blaise Boscaccy, Jonathan Corbet, Shuah Khan, James Morris,
Serge E. Hallyn, Eric Biggers, James.Bottomley,
linux-security-module
In-Reply-To: <CAKtyLkHtjzP3YsDr5-Gw0GRFB7Ch2h1amZzxy5taTt_+3gSzwQ@mail.gmail.com>
On Fri, May 29, 2026 at 8:57 PM Fan Wu <wufan@kernel.org> wrote:
>
> On Wed, May 27, 2026 at 8:09 PM Blaise Boscaccy
> <bboscaccy@linux.microsoft.com> wrote:
> >
> > In a multi-map hash verification scenario, a logic bug may have
> > allowed an attacker to provide duplicate maps to satisfy the hash
> > check count. Instead, invert the logic to verify each map discretely
> >
> > Signed-off-by: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
> > ---
>
> I just realized there is no audit event if hornet_check_prog_maps()
> fails, probably should add one.
Maybe, but I think it is important to remember that not all LSMs use
audit for reporting, and Hornet is doing some new things from an LSM
perspective. I think for right now it would be sufficient to use a
pr_notice() or a pr_notice_ratelimited() (if we are worried about
unpriv log spam) message in hornet_check_prog_maps(). Hornet can
always add proper audit support at a later date if deemed necessary.
Blaise, do you want to submit a patch to add pr_notice{_ratelimited}()
in the case of denial in hornet_check_prog_maps()?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 01/11] hornet: fix TOCTOU in signed program verification
From: Paul Moore @ 2026-06-02 3:25 UTC (permalink / raw)
To: Fan Wu
Cc: Blaise Boscaccy, Jonathan Corbet, Shuah Khan, James Morris,
Serge E. Hallyn, Eric Biggers, James.Bottomley,
linux-security-module
In-Reply-To: <CAKtyLkEy5QeWmozTr8v_CEFfJTK3WJq3CBr3h_T2=HMr9YfCFA@mail.gmail.com>
On Fri, May 29, 2026 at 9:11 PM Fan Wu <wufan@kernel.org> wrote:
> On Wed, May 27, 2026 at 8:09 PM Blaise Boscaccy
> <bboscaccy@linux.microsoft.com> wrote:
> >
> > The signature verification path was vulnerable to a time-of-check vs
> > time-of-use race at both the program load and program run hook sites:
> > between the moment a map's contents were hashed for signature
> > verification and the moment the program run hook re-verified them, an
> > attacker with sufficient privileges could swap or mutate the map
> > contents.
> >
> > Close the race by snapshotting the map hashes during program load,
> > attaching them to the program, and re-verifying them from the
> > security_bpf_prog hook against prog->aux->used_maps. Because used_maps
> > is the same map set the verifier and runtime resolve against, there is
> > no longer a window in which the verified set and the executed set can
> > diverge.
> >
> > Since we are no longer targeting the fd_array passed in, drop the map
> > index data entirely and check for whether or not the set of requested
> > map hashes is a subset of prog->aux->used_maps.
> >
> > Reported-by: Eric Biggers <ebiggers@kernel.org>
> > Signed-off-by: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
> > ---
> > Documentation/admin-guide/LSM/Hornet.rst | 39 +++-----
> > scripts/hornet/gen_sig.c | 17 +---
> > security/hornet/hornet.asn1 | 1 -
> > security/hornet/hornet_lsm.c | 121 +++--------------------
> > tools/testing/selftests/hornet/Makefile | 2 +-
> > 5 files changed, 35 insertions(+), 145 deletions(-)
A reminder to please trim your replies.
> > -static int hornet_verify_hashes(struct hornet_maps *maps,
> > - struct hornet_parse_context *ctx,
> > - struct bpf_prog *prog)
> > -{
> > - int map_fd;
> > - u32 i;
> > - struct bpf_map *map;
> > - int err = 0;
> > - unsigned char hash[SHA256_DIGEST_SIZE];
> > - struct hornet_prog_security_struct *security = hornet_bpf_prog_security(prog);
> > -
> > - for (i = 0; i < ctx->hash_count; i++) {
> > - if (ctx->skips[i])
> > - continue;
> > -
> > - err = copy_from_bpfptr_offset(&map_fd, maps->fd_array,
> > - ctx->indexes[i] * sizeof(map_fd),
> > - sizeof(map_fd));
> > - if (err != 0)
> > - return LSM_INT_VERDICT_FAULT;
>
> It seems this verdict is no longer used.
>
> > -
> > - CLASS(fd, f)(map_fd);
> > - if (fd_empty(f))
> > - return LSM_INT_VERDICT_FAULT;
> > - if (unlikely(fd_file(f)->f_op != &bpf_map_fops))
> > - return LSM_INT_VERDICT_FAULT;
> > -
> > - map = fd_file(f)->private_data;
> > - if (!READ_ONCE(map->frozen))
> > - return LSM_INT_VERDICT_FAULT;
> > -
> > - if (!map->ops->map_get_hash)
> > - return LSM_INT_VERDICT_FAULT;
> > -
> > - if (map->ops->map_get_hash(map, SHA256_DIGEST_SIZE, hash))
> > - return LSM_INT_VERDICT_FAULT;
> > -
> > - err = memcmp(hash, &ctx->hashes[i * SHA256_DIGEST_SIZE],
> > - SHA256_DIGEST_SIZE);
> > - if (err)
> > - return LSM_INT_VERDICT_UNEXPECTED;
>
> similar above, they should be removed for the header and for the ipe policy.
I would prefer to see LSM_INT_VERDICT_FAULT preserved as I think it is
good to have a verdict indicating a general error in the integrity
verification code, but I do agree with Fan that removing
VERDICT_UNEXPECTED is probably a good thing to do.
If Fan is insistent on removal of VERDICT_FAULT from the IPE code
that's fine, just leave it in the LSM header.
Can you get a patch out for this ASAP Blaise?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH net v2 4/4] netlabel: validate CIPSO option against skb tail in netlbl_skbuff_getattr
From: Paul Moore @ 2026-06-02 3:17 UTC (permalink / raw)
To: Qi Tang
Cc: davem, kuba, pabeni, edumazet, netdev, fw, lyutoon, stable,
Simon Horman, linux-security-module
In-Reply-To: <20260524041442.2432071-5-tpluszz77@gmail.com>
On Sun, May 24, 2026 at 12:15 AM Qi Tang <tpluszz77@gmail.com> wrote:
>
> netlbl_skbuff_getattr() locates the CIPSO option in the IPv4 IP header
> via cipso_v4_optptr() and hands the bare pointer to cipso_v4_getattr().
> The consumer re-reads cipso[1] (option length), cipso[6] (tag type),
> and then cipso_v4_parsetag_*() re-reads further bytes from the skb.
>
> __ip_options_compile() validates these bytes only at parse time. An
> nftables LOCAL_IN payload write reachable from an unprivileged user
> namespace can rewrite them after parse and before the SELinux/Smack
> peer-label consume path (selinux_sock_rcv_skb_compat ->
> selinux_netlbl_sock_rcv_skb -> netlbl_skbuff_getattr). This is the
> IPv4 analogue of the CALIPSO IPv6 trust-after-modification fixed in
> the previous patch: the tag parsers walk the option using attacker-
> controlled length bytes, producing slab-out-of-bounds reads whose
> contents feed into the MLS access decision.
>
> Validate the option fits within skb_tail_pointer(skb) before invoking
> cipso_v4_getattr(). The pre-tag-walk guard "ptr + 8 > tail" covers
> the CIPSO option header (type + length + DOI = 6 bytes) plus the
> first tag header (type + length = 2 bytes), which are the bytes
> cipso_v4_getattr() reads to dispatch on the tag. When the bounds
> check fails the packet has been mutated after parse, so return
> -EINVAL rather than fall through to the unlabeled path.
>
> Runtime confirmation (Smack peer-label policy + nft LOCAL_IN
> mutation of tag_len): UdpInDatagrams increments to 1 and recvfrom
> returns the payload, showing netlbl_skbuff_getattr ->
> cipso_v4_getattr -> cipso_v4_parsetag_rbm -> netlbl_bitmap_walk runs
> end-to-end past the option's true bound; with this patch the
> consume path returns -EINVAL at the bounds check and the counter
> stays 0.
>
> Cc: stable@vger.kernel.org
> Reported-by: Qi Tang <tpluszz77@gmail.com>
> Reported-by: Tong Liu <lyutoon@gmail.com>
> Fixes: 04f81f0154e4 ("cipso: don't use IPCB() to locate the CIPSO IP option")
> Signed-off-by: Qi Tang <tpluszz77@gmail.com>
> ---
> net/netlabel/netlabel_kapi.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
> index d0d6220b8d59d..c2d3ea751f4e1 100644
> --- a/net/netlabel/netlabel_kapi.c
> +++ b/net/netlabel/netlabel_kapi.c
> @@ -1393,11 +1393,24 @@ int netlbl_skbuff_getattr(const struct sk_buff *skb,
> unsigned char *ptr;
>
> switch (family) {
> - case AF_INET:
> + case AF_INET: {
> + const unsigned char *tail = skb_tail_pointer(skb);
> + u8 opt_len, tag_len;
> +
> ptr = cipso_v4_optptr(skb);
> - if (ptr && cipso_v4_getattr(ptr, secattr) == 0)
> + if (!ptr)
> + break;
> + /* CIPSO header (type+len+DOI = 6) + first tag header (type+len = 2) */
> + if (ptr + 8 > tail)
> + return -EINVAL;
> + opt_len = ptr[1]; /* total CIPSO option length */
> + tag_len = ptr[7]; /* first tag length */
> + if (ptr + opt_len > tail || ptr + 6 + tag_len > tail)
> + return -EINVAL;
> + if (cipso_v4_getattr(ptr, secattr) == 0)
> return 0;
I'd strongly prefer if you moved the tag length check into
cipso_v4_getattr(). As you've already validated the CIPSO option
length field it should be a fairly easy check, no need to test it
against the skb's tail pointer, just ensure the tag length doesn't go
past the end of the CIPSO option.
> break;
> + }
> #if IS_ENABLED(CONFIG_IPV6)
> case AF_INET6: {
> const unsigned char *tail = skb_tail_pointer(skb);
> --
> 2.47.3
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH net v2] netlabel: validate unlabeled mask attribute length
From: Paul Moore @ 2026-06-02 3:08 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Chenguang Zhao, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, netdev, linux-security-module
In-Reply-To: <20260601193805.011c7f15@kernel.org>
On Mon, Jun 1, 2026 at 10:38 PM Jakub Kicinski <kuba@kernel.org> wrote:
> On Thu, 28 May 2026 09:59:13 +0800 Chenguang Zhao wrote:
> > netlbl_unlabel_addrinfo_get() checked the address length
> > but allowed shorter mask attributes to pass through to
> > fixed-size address reads.
> >
> > netlbl_unlabel_addrinfo_get() only rejected a mask
> > length mismatch when the address attribute length
> > was also invalid. A crafted Generic Netlink request
> > could therefore provide a valid IPv4/IPv6 address
> > attribute with a shorter mask attribute.
> >
> > NLA_BINARY policy lengths are maximum lengths,
> > not exact lengths, so the short mask can pass
> > policy validation. The mask is later read as
> > a full struct in_addr or struct in6_addr.
> > Require both address and mask attributes to
> > have the exact expected size.
>
> Sorry, didn't look at this until Paul responded.
>
> NLA_BINARY does _default_ to maximum lengths.
> But you can use NLA_POLICY_EXACT_LEN() to have the policy do the right
> thing. Using the policy is preferred - less code, and policy
> introspection informs user space about the expectations.
Thanks, I didn't know NLA_POLICY_EXACT_LEN() existed, and yes, I
agree, that would be a much better way to solve this problem.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH net v2 3/4] netlabel: validate CALIPSO option against skb tail in netlbl_skbuff_getattr
From: Paul Moore @ 2026-06-02 3:02 UTC (permalink / raw)
To: Qi Tang
Cc: davem, kuba, pabeni, edumazet, netdev, fw, lyutoon, stable,
Simon Horman, Huw Davies, linux-security-module
In-Reply-To: <20260524041442.2432071-4-tpluszz77@gmail.com>
On Sun, May 24, 2026 at 12:15 AM Qi Tang <tpluszz77@gmail.com> wrote:
>
> netlbl_skbuff_getattr() locates the CALIPSO option in the IPv6 HBH
> header via calipso_optptr() and hands the bare pointer to
> calipso_getattr() -> calipso_opt_getattr(). The consumer re-reads
> calipso[1] (option data length) and calipso[6] (cat_len/4) and walks
> calipso + 10 for cat_len bytes via netlbl_bitmap_walk().
>
> ipv6_hop_calipso() validates these bytes only at parse time inside
> ipv6_parse_hopopts(). An nftables PRE_ROUTING payload write reachable
> from an unprivileged user namespace can rewrite both bytes between
> parse and the SELinux peer-label consume path
> (selinux_sock_rcv_skb_compat -> selinux_netlbl_sock_rcv_skb ->
> netlbl_skbuff_getattr). The self-consistency check
> (cat_len + 8 > len) inside calipso_opt_getattr() is defeated by
> mutating both bytes consistently, allowing a ~232-byte
> slab-out-of-bounds read from calipso + 10 whose set bits become MLS
> categories driving the access decision.
>
> netlbl_skbuff_getattr() has the skb; gate the consume on the option
> fitting within skb_tail_pointer(). The IPv6 option layout is
> type(1) + length(1) + length bytes of data, so requiring
> ptr + 2 + ptr[1] <= skb_tail covers the option and its embedded
> bitmap. When the bounds check fails the packet has been mutated
> after parse, so return -EINVAL rather than fall through to the
> unlabeled path.
>
> Runtime confirmation (SELinux compat path with selinux=1 enforcing=0
> and a CALIPSO DOI added via netlabelctl): Udp6InDatagrams increments
> to 1 with the mutated cat_len, showing
> selinux_socket_sock_rcv_skb -> netlbl_skbuff_getattr ->
> calipso_opt_getattr -> netlbl_bitmap_walk runs end-to-end past the
> option's true bound; with this patch the consume path returns
> -EINVAL at the bounds check and the counter stays 0.
>
> Cc: stable@vger.kernel.org
> Reported-by: Qi Tang <tpluszz77@gmail.com>
> Reported-by: Tong Liu <lyutoon@gmail.com>
> Fixes: 2917f57b6bc1 ("calipso: Allow the lsm to label the skbuff directly.")
> Signed-off-by: Qi Tang <tpluszz77@gmail.com>
> ---
> net/netlabel/netlabel_kapi.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
Thanks for the fix.
Acked-by: Paul Moore <paul@paul-moore.com>
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH net v2] netlabel: validate unlabeled mask attribute length
From: Jakub Kicinski @ 2026-06-02 2:38 UTC (permalink / raw)
To: Chenguang Zhao
Cc: Paul Moore, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, netdev, linux-security-module
In-Reply-To: <20260528015913.190970-1-zhaochenguang@kylinos.cn>
On Thu, 28 May 2026 09:59:13 +0800 Chenguang Zhao wrote:
> netlbl_unlabel_addrinfo_get() checked the address length
> but allowed shorter mask attributes to pass through to
> fixed-size address reads.
>
> netlbl_unlabel_addrinfo_get() only rejected a mask
> length mismatch when the address attribute length
> was also invalid. A crafted Generic Netlink request
> could therefore provide a valid IPv4/IPv6 address
> attribute with a shorter mask attribute.
>
> NLA_BINARY policy lengths are maximum lengths,
> not exact lengths, so the short mask can pass
> policy validation. The mask is later read as
> a full struct in_addr or struct in6_addr.
> Require both address and mask attributes to
> have the exact expected size.
Sorry, didn't look at this until Paul responded.
NLA_BINARY does _default_ to maximum lengths.
But you can use NLA_POLICY_EXACT_LEN() to have the policy do the right
thing. Using the policy is preferred - less code, and policy
introspection informs user space about the expectations.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v5 4/4] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Jarkko Sakkinen @ 2026-06-02 2:29 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity, paul, zohar,
roberto.sassu, noodles, sudeep.holla, jmorris, serge,
dmitry.kasatkin, eric.snowberg, jgg
In-Reply-To: <20260601142749.3379697-5-yeoreum.yun@arm.com>
On Mon, Jun 01, 2026 at 03:27:49PM +0100, Yeoreum Yun wrote:
> commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
> probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
>
> However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
> initialises IMA at the late_initcall_sync level, so this change is no
> longer required.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> ---
> drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> index 99f1c1e5644b..025c4d4b17ca 100644
> --- a/drivers/char/tpm/tpm_crb_ffa.c
> +++ b/drivers/char/tpm/tpm_crb_ffa.c
> @@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> */
> int tpm_crb_ffa_init(void)
> {
> - int ret = 0;
> -
> - if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> - ret = ffa_register(&tpm_crb_ffa_driver);
> - if (ret) {
> - tpm_crb_ffa = ERR_PTR(-ENODEV);
> - return ret;
> - }
> - }
> -
> if (!tpm_crb_ffa)
> - ret = -ENOENT;
> + return -ENOENT;
>
> if (IS_ERR_VALUE(tpm_crb_ffa))
> - ret = -ENODEV;
> + return -ENODEV;
>
> - return ret;
> + return 0;
> }
> EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
>
> @@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
> .id_table = tpm_crb_ffa_device_id,
> };
>
> -#ifdef MODULE
> module_ffa_driver(tpm_crb_ffa_driver);
> -#endif
>
> MODULE_AUTHOR("Arm");
> MODULE_DESCRIPTION("TPM CRB FFA driver");
> --
> LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH net v2] netlabel: validate unlabeled mask attribute length
From: Paul Moore @ 2026-06-02 2:25 UTC (permalink / raw)
To: Chenguang Zhao
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev, linux-security-module
In-Reply-To: <20260528015913.190970-1-zhaochenguang@kylinos.cn>
On Wed, May 27, 2026 at 9:59 PM Chenguang Zhao <zhaochenguang@kylinos.cn> wrote:
>
> netlbl_unlabel_addrinfo_get() checked the address length
> but allowed shorter mask attributes to pass through to
> fixed-size address reads.
>
> netlbl_unlabel_addrinfo_get() only rejected a mask
> length mismatch when the address attribute length
> was also invalid. A crafted Generic Netlink request
> could therefore provide a valid IPv4/IPv6 address
> attribute with a shorter mask attribute.
>
> NLA_BINARY policy lengths are maximum lengths,
> not exact lengths, so the short mask can pass
> policy validation. The mask is later read as
> a full struct in_addr or struct in6_addr.
> Require both address and mask attributes to
> have the exact expected size.
>
> Fixes: 8cc44579d1bd ("NetLabel: Introduce static network labels for unlabeled connections")
> Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
> ---
> v2:
> - Adjust commit message
> - Add Fixes and 'net' subject prefix.
> v1:
> https://lore.kernel.org/all/20260522054521.1169755-1-zhaochenguang@kylinos.cn/
> ---
> net/netlabel/netlabel_unlabeled.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
Looks good to me, thanks!
Acked-by: Paul Moore <paul@paul-moore.com>
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH RESEND 1/1] yama: clean-up ptrace relations upon activating YAMA_SCOPE_NO_ATTACH
From: Paul Moore @ 2026-06-02 1:59 UTC (permalink / raw)
To: Ethan Ferguson, kees; +Cc: jmorris, serge, linux-security-module, linux-kernel
In-Reply-To: <20260526153542.105483-2-ethan.ferguson@zetier.com>
On Tue, May 26, 2026 at 11:35 AM Ethan Ferguson
<ethan.ferguson@zetier.com> wrote:
>
> Clean up ptracer_relations upon YAMA_SCOPE_NO_ATTACH, and prevent
> further modification by processes.
>
> Signed-off-by: Ethan Ferguson <ethan.ferguson@zetier.com>
>
> ---
> security/yama/yama_lsm.c | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
Kees, I've got no comment on the patch itself, just wanted to make
sure you saw the resend.
> diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
> index cef3776cf3b2..3b7c5384e6bc 100644
> --- a/security/yama/yama_lsm.c
> +++ b/security/yama/yama_lsm.c
> @@ -26,6 +26,7 @@
> #define YAMA_SCOPE_NO_ATTACH 3
>
> static int ptrace_scope = YAMA_SCOPE_RELATIONAL;
> +static int max_scope = YAMA_SCOPE_NO_ATTACH;
>
> /* describe a ptrace relationship for potential exception */
> struct ptrace_relation {
> @@ -119,7 +120,7 @@ static void yama_relation_cleanup(struct work_struct *work)
> spin_lock(&ptracer_relations_lock);
> rcu_read_lock();
> list_for_each_entry_rcu(relation, &ptracer_relations, node) {
> - if (relation->invalid) {
> + if (relation->invalid || ptrace_scope == max_scope) {
> list_del_rcu(&relation->node);
> kfree_rcu(relation, rcu);
> }
> @@ -204,7 +205,8 @@ static void yama_ptracer_del(struct task_struct *tracer,
> */
> static void yama_task_free(struct task_struct *task)
> {
> - yama_ptracer_del(task, task);
> + if (ptrace_scope <= max_scope)
> + yama_ptracer_del(task, task);
> }
>
> /**
> @@ -224,6 +226,9 @@ static int yama_task_prctl(int option, unsigned long arg2, unsigned long arg3,
> int rc = -ENOSYS;
> struct task_struct *myself;
>
> + if (ptrace_scope == max_scope)
> + return -EPERM;
> +
> switch (option) {
> case PR_SET_PTRACER:
> /* Since a thread can call prctl(), find the group leader
> @@ -432,6 +437,7 @@ static struct security_hook_list yama_hooks[] __ro_after_init = {
> static int yama_dointvec_minmax(const struct ctl_table *table, int write,
> void *buffer, size_t *lenp, loff_t *ppos)
> {
> + int ret;
> struct ctl_table table_copy;
>
> if (write && !capable(CAP_SYS_PTRACE))
> @@ -442,10 +448,17 @@ static int yama_dointvec_minmax(const struct ctl_table *table, int write,
> if (*(int *)table_copy.data == *(int *)table_copy.extra2)
> table_copy.extra1 = table_copy.extra2;
>
> - return proc_dointvec_minmax(&table_copy, write, buffer, lenp, ppos);
> -}
> + ret = proc_dointvec_minmax(&table_copy, write, buffer, lenp, ppos);
> + if (ret < 0)
> + return ret;
>
> -static int max_scope = YAMA_SCOPE_NO_ATTACH;
> + /* If max_scope was just activated in this call */
> + if (*(int *)table_copy.data == *(int *)table_copy.extra2 &&
> + table_copy.extra1 != table_copy.extra2)
> + schedule_work(&yama_relation_work);
> +
> + return 0;
> +}
>
> static const struct ctl_table yama_sysctl_table[] = {
> {
> --
> 2.43.0
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v4 3/3] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Jarkko Sakkinen @ 2026-06-02 1:55 UTC (permalink / raw)
To: Yeoreum Yun
Cc: Sudeep Holla, linux-security-module, linux-kernel,
linux-integrity, paul, zohar, roberto.sassu, noodles, jmorris,
serge, dmitry.kasatkin, eric.snowberg, jgg
In-Reply-To: <ah1YjJJmrkecklko@e129823.arm.com>
On Mon, Jun 01, 2026 at 11:01:48AM +0100, Yeoreum Yun wrote:
> > On Mon, Jun 01, 2026 at 08:17:13AM +0100, Yeoreum Yun wrote:
> > > Hi Jarkko,
> > >
> > > Sorry for late answer.
> > >
> > > > On Mon, May 25, 2026 at 08:54:04AM +0100, Yeoreum Yun wrote:
> > > > > commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
> > > > > probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
> > > > >
> > > > > However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
> > > > > initialises IMA at the late_initcall_sync level, so this change is no
> > > > > longer required.
> > > > >
> > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > ---
> > > > > drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
> > > > > 1 file changed, 3 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> > > > > index 99f1c1e5644b..025c4d4b17ca 100644
> > > > > --- a/drivers/char/tpm/tpm_crb_ffa.c
> > > > > +++ b/drivers/char/tpm/tpm_crb_ffa.c
> > > > > @@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> > > > > */
> > > > > int tpm_crb_ffa_init(void)
> > > > > {
> > > > > - int ret = 0;
> > > > > -
> > > > > - if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> > > > > - ret = ffa_register(&tpm_crb_ffa_driver);
> > > > > - if (ret) {
> > > > > - tpm_crb_ffa = ERR_PTR(-ENODEV);
> > > > > - return ret;
> > > > > - }
> > > > > - }
> > > > > -
> > > > > if (!tpm_crb_ffa)
> > > > > - ret = -ENOENT;
> > > > > + return -ENOENT;
> > > > >
> > > > > if (IS_ERR_VALUE(tpm_crb_ffa))
> > > > > - ret = -ENODEV;
> > > > > + return -ENODEV;
> > > > >
> > > > > - return ret;
> > > > > + return 0;
> > > > > }
> > > > > EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
> > > > >
> > > > > @@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
> > > > > .id_table = tpm_crb_ffa_device_id,
> > > > > };
> > > > >
> > > > > -#ifdef MODULE
> > > > > module_ffa_driver(tpm_crb_ffa_driver);
> > > > > -#endif
> > > > >
> > > > > MODULE_AUTHOR("Arm");
> > > > > MODULE_DESCRIPTION("TPM CRB FFA driver");
> > > > > --
> > > > > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
> > > > >
> > > >
> > > > How we would sync up this patch? Through which tree etc.
> > >
> > > IMHO, the IMA relevant thing would be into IMA tree,
> > > However I think this patch would be much easier to sync into Sudeep's
> > > FF-A tree where ff-a initilisation is reverted to device_initcall
> > > unless you're uncomfortable.
> > >
> > > For this, It might be better to split this patch from this series
> > > since by above and defer probe of ff-a would make a register failure
> > > of registering tpm_crb_ffa driver which is built-in.
> > >
> > > @Sudeep what do you think?
> > >
> >
> > IIRC, there is/was no dependency between these and FF-A patches that are
> > queued in terms of build. I agree there may be dependency to get all the
> > functionality but we can resort to linux-next for that. FF-A is not enabled
> > in the defconfig, so anyone working on FF-A + TPM must enable then and can
> > rely on -next IMHO.
> >
> > That said, I have already sent PR for FF-A to SoC team and it is already
> > queued for v7.2. I don't have any other plans unless they are fixes.
>
> Thanks. Then I think it's enough to merge this patch to TPM tree
> when this patchset is approved once.
Oops, sorry I've forgot to tag this although I've mentally accepted
this (which does not unfortunately help move things forward):
It's probably better just put SOB to the tail, or least messiest
I think:
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> --
> Sincerely,
> Yeoreum Yun
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v4 3/3] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Jarkko Sakkinen @ 2026-06-02 1:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: Yeoreum Yun, linux-security-module, linux-kernel, linux-integrity,
paul, zohar, roberto.sassu, noodles, jmorris, serge,
dmitry.kasatkin, eric.snowberg, jgg
In-Reply-To: <20260601-shiny-steel-jellyfish-b38b6e@sudeepholla>
On Mon, Jun 01, 2026 at 09:54:08AM +0100, Sudeep Holla wrote:
> On Mon, Jun 01, 2026 at 08:17:13AM +0100, Yeoreum Yun wrote:
> > Hi Jarkko,
> >
> > Sorry for late answer.
> >
> > > On Mon, May 25, 2026 at 08:54:04AM +0100, Yeoreum Yun wrote:
> > > > commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
> > > > probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
> > > >
> > > > However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
> > > > initialises IMA at the late_initcall_sync level, so this change is no
> > > > longer required.
> > > >
> > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > ---
> > > > drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
> > > > 1 file changed, 3 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> > > > index 99f1c1e5644b..025c4d4b17ca 100644
> > > > --- a/drivers/char/tpm/tpm_crb_ffa.c
> > > > +++ b/drivers/char/tpm/tpm_crb_ffa.c
> > > > @@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> > > > */
> > > > int tpm_crb_ffa_init(void)
> > > > {
> > > > - int ret = 0;
> > > > -
> > > > - if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> > > > - ret = ffa_register(&tpm_crb_ffa_driver);
> > > > - if (ret) {
> > > > - tpm_crb_ffa = ERR_PTR(-ENODEV);
> > > > - return ret;
> > > > - }
> > > > - }
> > > > -
> > > > if (!tpm_crb_ffa)
> > > > - ret = -ENOENT;
> > > > + return -ENOENT;
> > > >
> > > > if (IS_ERR_VALUE(tpm_crb_ffa))
> > > > - ret = -ENODEV;
> > > > + return -ENODEV;
> > > >
> > > > - return ret;
> > > > + return 0;
> > > > }
> > > > EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
> > > >
> > > > @@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
> > > > .id_table = tpm_crb_ffa_device_id,
> > > > };
> > > >
> > > > -#ifdef MODULE
> > > > module_ffa_driver(tpm_crb_ffa_driver);
> > > > -#endif
> > > >
> > > > MODULE_AUTHOR("Arm");
> > > > MODULE_DESCRIPTION("TPM CRB FFA driver");
> > > > --
> > > > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
> > > >
> > >
> > > How we would sync up this patch? Through which tree etc.
> >
> > IMHO, the IMA relevant thing would be into IMA tree,
> > However I think this patch would be much easier to sync into Sudeep's
> > FF-A tree where ff-a initilisation is reverted to device_initcall
> > unless you're uncomfortable.
> >
> > For this, It might be better to split this patch from this series
> > since by above and defer probe of ff-a would make a register failure
> > of registering tpm_crb_ffa driver which is built-in.
> >
> > @Sudeep what do you think?
> >
>
> IIRC, there is/was no dependency between these and FF-A patches that are
> queued in terms of build. I agree there may be dependency to get all the
> functionality but we can resort to linux-next for that. FF-A is not enabled
> in the defconfig, so anyone working on FF-A + TPM must enable then and can
> rely on -next IMHO.
>
> That said, I have already sent PR for FF-A to SoC team and it is already
> queued for v7.2. I don't have any other plans unless they are fixes.
Works for me.
>
> --
> Regards,
> Sudeep
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v4 3/3] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Jarkko Sakkinen @ 2026-06-02 1:45 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity, paul, zohar,
roberto.sassu, noodles, sudeep.holla, jmorris, serge,
dmitry.kasatkin, eric.snowberg, jgg
In-Reply-To: <ah0x+YDypYFzpFqt@e129823.arm.com>
On Mon, Jun 01, 2026 at 08:17:13AM +0100, Yeoreum Yun wrote:
> Hi Jarkko,
>
> Sorry for late answer.
it's all good, there's been a bug storm so I'm glad that you have not been
around ;-)
BR, Jarkko
>
> > On Mon, May 25, 2026 at 08:54:04AM +0100, Yeoreum Yun wrote:
> > > commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
> > > probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
> > >
> > > However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
> > > initialises IMA at the late_initcall_sync level, so this change is no
> > > longer required.
> > >
> > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > ---
> > > drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
> > > 1 file changed, 3 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> > > index 99f1c1e5644b..025c4d4b17ca 100644
> > > --- a/drivers/char/tpm/tpm_crb_ffa.c
> > > +++ b/drivers/char/tpm/tpm_crb_ffa.c
> > > @@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> > > */
> > > int tpm_crb_ffa_init(void)
> > > {
> > > - int ret = 0;
> > > -
> > > - if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> > > - ret = ffa_register(&tpm_crb_ffa_driver);
> > > - if (ret) {
> > > - tpm_crb_ffa = ERR_PTR(-ENODEV);
> > > - return ret;
> > > - }
> > > - }
> > > -
> > > if (!tpm_crb_ffa)
> > > - ret = -ENOENT;
> > > + return -ENOENT;
> > >
> > > if (IS_ERR_VALUE(tpm_crb_ffa))
> > > - ret = -ENODEV;
> > > + return -ENODEV;
> > >
> > > - return ret;
> > > + return 0;
> > > }
> > > EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
> > >
> > > @@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
> > > .id_table = tpm_crb_ffa_device_id,
> > > };
> > >
> > > -#ifdef MODULE
> > > module_ffa_driver(tpm_crb_ffa_driver);
> > > -#endif
> > >
> > > MODULE_AUTHOR("Arm");
> > > MODULE_DESCRIPTION("TPM CRB FFA driver");
> > > --
> > > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
> > >
> >
> > How we would sync up this patch? Through which tree etc.
>
> IMHO, the IMA relevant thing would be into IMA tree,
> However I think this patch would be much easier to sync into Sudeep's
> FF-A tree where ff-a initilisation is reverted to device_initcall
> unless you're uncomfortable.
>
> For this, It might be better to split this patch from this series
> since by above and defer probe of ff-a would make a register failure
> of registering tpm_crb_ffa driver which is built-in.
>
> @Sudeep what do you think?
>
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/commit/?h=for-next/ffa/updates&id=cc7e8f21b9f0c229d68cf19a837cba82b5ac2d87 [0]
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/commit/?h=for-next/ffa/updates&id=e659fc8e537c7a21d5d693d6f30d8852f2fa8d91 [1]
>
> --
> Sincerely,
> Yeoreum Yun
^ permalink raw reply
* Landstrip
From: Jarkko Sakkinen @ 2026-06-02 1:42 UTC (permalink / raw)
To: linux-integrity; +Cc: linux-security-module
I played with an idea could Landlock LSM be used to do conceptually a
better fit sandbox for programs such as Anthropic Sandbox Runtime [1].
After some missteps at first I got it pulled together quite well:
https://crates.io/crates/landstrip
To see it in action I also have a fork of pi-hashline-readmap plugin,
which was a cherry-picked test case I wanted to try out given it already
hooks the bash tool command for compressed output.
I just thought that this might interest some as Landlock is not really
over-used kernel feature in "application sense".
This is a more lower barrier and more failure tolerant to deploy than
Bubblewrap based container for this use and purpose in my opinion
at least.
[1] https://github.com/anthropic-experimental/sandbox-runtime/issues/291
[2] https://github.com/jarkkojs/pi-hashline-readmap
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v5 11/13] ima: Support staging and deleting N measurements entries
From: steven chen @ 2026-06-01 23:28 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, corbet, skhan, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu, steven chen
In-Reply-To: <f00aabe05aeee7f6fd0426fd992839758d810da7.camel@linux.ibm.com>
On 5/26/2026 4:08 AM, Mimi Zohar wrote:
> On Wed, 2026-04-29 at 18:03 +0200, Roberto Sassu wrote:
>> From: Roberto Sassu <roberto.sassu@huawei.com>
>>
>> Add support for sending a value N between 1 and ULONG_MAX to the IMA
>> original measurement interface. This value represents the number of
>> measurements that should be deleted from the current measurements list. In
>> this case, measurements are staged in an internal non-user visible list,
>> and immediately deleted.
>>
>> This staging method allows the remote attestation agents to easily separate
>> the measurements that were verified (staged and deleted) from those that
>> weren't due to the race between taking a TPM quote and reading the
>> measurements list.
> The reason for removing records from the IMA measurement list is to free kernel
> memory. However, the level of precision in removing only those measurements
> needed for the quote seems necessary only if the measurement records are not
> being saved. Upstreaming a feature to remove measurement records from the IMA
> measurement list is to address the kernel memory issue — clearly not to drop
> measurement records and break attestation.
>
>> In order to minimize the locking time of ima_extend_list_mutex, deleting
>> N entries is realized by doing a lockless walk in the current measurements
>> list to determine the N-th entry to cut, to cut the current measurements
>> list under the lock, and by deleting the excess entries after releasing the
>> lock.
>>
>> Flushing the hash table is not supported for N entries, since it would
>> require removing the N entries one by one from the hash table under the
>> ima_extend_list_mutex lock, which would increase the locking time.
>>
>> The ima_extend_list_mutex lock is necessary in ima_dump_measurement_list()
>> because ima_queue_delete_partial() uses __list_cut_position() to modify
>> ima_measurements, for which no RCU-safe variant exists. For the staging
>> with prompt flavor alone, list_replace_rcu() could have been used instead,
>> but since both flavors share the same kexec serialization path, the mutex
>> is required regardless.
> Thank you for the clear explanation for the changes and limitations required to
> support this feature.
>
> The changes needed for supporting "stage and delete N" measurement records
> should be limited to this patch. Patch 9/13 should have used
> list_replace_rcu(), without the mutex_lock.
>
>> Link: https://github.com/linux-integrity/linux/issues/1
>> Suggested-by: Steven Chen <chenste@linux.microsoft.com>
>> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Otherwise,
>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Tested-by: Steven Chen <chenste@linux.microsoft.com>
Reviewed-by: Steven Chen <chenste@linux.microsoft.com>
^ permalink raw reply
* Re: [PATCH v4 0/2] Delete task_euid()
From: Paul Moore @ 2026-06-01 23:13 UTC (permalink / raw)
To: Alice Ryhl
Cc: Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman, Shuah Khan,
Alex Shi, Yanteng Si, Dongliang Mu, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Jann Horn, linux-security-module,
linux-doc, linux-kernel, rust-for-linux
In-Reply-To: <20260529-remove-task-euid-v4-0-07cbdf3af980@google.com>
On Fri, May 29, 2026 at 5:33 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> The task_euid() method is a very weird method, and Binder was the only
> user. As of commit 65b672152289 ("binder: use current_euid() for
> transaction sender identity") Binder doesn't use task_euid() anymore,
> so we can delete this method.
Given the problems from last time, it seems like it might be prudent
to let the commit have some time to "breathe" in a proper release, I'd
suggest merging this not for the upcoming v7.2 merge window but
instead waiting for v7.3.
> My suggestion would be to merge this through the LSM tree.
That's fine with me. I'd also suggest updating the commit description
in patch 1/2 to indicate that binder is no longer using task_euid();
it currently reads like it is still being used.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 1/2] landlock: fix LANDLOCK_SCOPE_SIGNAL bypass via F_SETOWN to invoker's pgid
From: Günther Noack @ 2026-06-01 22:08 UTC (permalink / raw)
To: hexlabsecurity
Cc: Mickaël Salaün, Justin Suess, gnoack@google.com,
linux-security-module@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <7rvmLIHR1Zh8RDF1IY1-SYRHzErgw9gPHq0k98RLYVsmHqAejjxcuJi8V3QaSbW-SnNvY5tfM2Xn_S1dEajKV_f7iyitoPwJgOSTZQ0nytc=@proton.me>
On Fri, May 29, 2026 at 07:07:30PM +0000, hexlabsecurity@proton.me wrote:
> From b5fdc79ce1cb2881d59dfed01d3d9170306be9e8 Mon Sep 17 00:00:00 2001
> From: Bryam Vargas <hexlabsecurity@proton.me>
> Date: Fri, 29 May 2026 12:49:41 -0500
> Subject: [PATCH v3 1/2] landlock: fix LANDLOCK_SCOPE_SIGNAL bypass via
> F_SETOWN to invoker's pgid
>
> A Landlock-restricted process can bypass LANDLOCK_SCOPE_SIGNAL on the
> SIGIO delivery path and deliver arbitrary signals (including SIGKILL via
> F_SETSIG) to non-Landlocked targets that share its pgid, by exploiting a
> producer-side cache-vs-live evaluation gap.
>
> The SIGIO path in hook_file_send_sigiotask() consults a cached subject
> stored in landlock_file(file)->fown_subject at fcntl(F_SETOWN) time
> (via hook_file_set_fowner()), instead of evaluating the live Landlock
> domain of the invoking task at signal-send time. The capture is gated
> by control_current_fowner(), which returns false (skipping capture)
> when pid_task(fown->pid, fown->pid_type) is in current's thread group.
>
> This is correct for PIDTYPE_TGID / PIDTYPE_PID, where the target is a
> single task sharing current's cred. It is unsafe for PIDTYPE_PGID and
> PIDTYPE_SID: when current is at the head of its pgid hlist -- the
> default placement after fork(), hlist_add_head_rcu() in kernel/fork.c --
> pid_task(pgid, PIDTYPE_PGID) resolves to current itself,
> same_thread_group(current, current) is true, the capture is skipped, and
> fown_subject.domain stays NULL. hook_file_send_sigiotask() then
> short-circuits at "if (!subject->domain) return 0;", letting the kernel
> fan the signal out to every member of the group, including tasks outside
> current's Landlock domain that SCOPE_SIGNAL is supposed to protect.
>
> The direct kill() path (hook_task_kill) is unaffected: it evaluates
> current's live domain on every call. Only the cached SIGIO path is
> broken.
>
> Tighten control_current_fowner() to apply the thread-group exemption
> only when the target identifies a single task whose Landlock cred is
> necessarily shared with current (PIDTYPE_TGID, PIDTYPE_PID). For
> PIDTYPE_PGID and PIDTYPE_SID, always capture the current Landlock
> subject so the consumer's scope check runs against every member of the
> group at delivery time.
>
> Stable kernels before the fown_subject conversion store the domain in
> landlock_file(file)->fown_domain; control_current_fowner() is identical
> there, so the same exemption and the same fix apply.
>
> Fixes: 18eb75f3af40 ("landlock: Always allow signals between threads of the same process")
> Cc: stable@vger.kernel.org
> Reported-by: Bryam Vargas <hexlabsecurity@proton.me>
> Tested-by: Justin Suess <utilityemal77@gmail.com>
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
> ---
> security/landlock/fs.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> index c1ecfe239032..edaa52572cbd 100644
> --- a/security/landlock/fs.c
> +++ b/security/landlock/fs.c
> @@ -1909,6 +1909,18 @@ static bool control_current_fowner(struct fown_struct *const fown)
> if (!p)
> return true;
>
> + /*
> + * For PIDTYPE_PGID and PIDTYPE_SID, signal delivery fans out to
> + * every member of the group at SIGIO time. Even when pid_task()
> + * resolves to current itself (e.g., current is the pgid hlist
> + * head post-fork), non-current members of the group are still
> + * valid targets that must be checked by hook_file_send_sigiotask().
> + * Always capture the current subject for those types so the
> + * consumer scope check runs against the live fown_subject.
> + */
> + if (fown->pid_type == PIDTYPE_PGID || fown->pid_type == PIDTYPE_SID)
> + return true;
> +
> return !same_thread_group(p, current);
> }
The reason why the same_thread_group() check exists is so that Go
programs that had to use libpsx instead of TSYNC had a way to signal
their own OS threads at the C level (a feature used by linked C
libraries and specifically by libpsx itself, so it prevented nested
Landlock domains).
(a) On Linux 7.0, the Go-Landlock library automatically uses TSYNC so
this is not a problem any more.
(b) On earlier Linux versions
* libpsx signaling is also going to continue working,
because it uses normal signals instead of SIGIO
* other libraries are also likely to continue working, unless they
use the somewhat obscure SIGIO with PIDTYPE_PGID or PIDTYPE_SID.
There is little incentive to use SIGIO in a pure Go program, as
the runtime already implements file descriptor polling logic (with
epoll, which is anyway a better choice)
So, this looks fine from the Go perspective; I doubt that this has
practical implications for Go.
Thank you for spotting this and providing a fix! 🙏
–Günther
^ permalink raw reply
* Re: [PATCH 01/11] params: bound array element output to the caller's page buffer
From: Matthew Wilcox @ 2026-06-01 20:23 UTC (permalink / raw)
To: David Laight
Cc: Kees Cook, Luis Chamberlain, Pengpeng Hou, stable, Petr Pavlu,
Richard Weinberger, Anton Ivanov, Johannes Berg,
Rafael J. Wysocki, Len Brown, Corey Minyard, Gabriel Somlo,
Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Simona Vetter, Bart Van Assche,
Jason Gunthorpe, Leon Romanovsky, Laurent Pinchart, Hans de Goede,
Mauro Carvalho Chehab, Bjorn Helgaas, Hannes Reinecke,
James E.J. Bottomley, Martin K. Petersen, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Greg Kroah-Hartman, Jiri Slaby,
Alan Stern, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Jason Baron, Jim Cromie, Tiwei Bie, Benjamin Berg,
Ilpo Järvinen, David E. Box, Maciej W. Rozycki,
Srinivas Pandruvada, Peter Zijlstra, Heiko Carstens,
Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521174631.71a06440@pumpkin>
On Thu, May 21, 2026 at 05:46:31PM +0100, David Laight wrote:
> On Thu, 21 May 2026 06:33:14 -0700
> Kees Cook <kees@kernel.org> wrote:
> > Collect each element into a temporary PAGE_SIZE buffer first and then
> > copy only the remaining space into the caller's page buffer.
>
> Should this be using a 4k buffer on all architectures?
> Initially perhaps just using a different name for the constant until
> all the associated PAGE_SIZE limits have been removed.
If we're acually going to think about this, even 4KiB is too big.
An 80x25 terminal is 2000 bytes (assuming no utf8), so 4KiB is two
entire screenfuls. Limiting to 2048 would seem reasonable to me.
^ permalink raw reply
* Re: [PATCH 00/11] Convert moduleparams to seq_buf
From: Kees Cook @ 2026-06-01 19:59 UTC (permalink / raw)
To: Petr Pavlu
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <88c5ca1d-eeda-4023-bc7a-397b92780db9@suse.com>
On Tue, May 26, 2026 at 08:53:06AM +0200, Petr Pavlu wrote:
> On 5/21/26 3:33 PM, Kees Cook wrote:
> > Hi,
> >
> > I tried to trim the CC list here, but it's still pretty huge...
> >
> > We've had a long-standing issue with "write to a string pointer" callbacks
> > that don't bounds check the destination (and for which the bounds is
> > also not part of the callback prototype, even if it is "known" to be
> > PAGE_SIZE, which sysfs_emit() depends on). Both moduleparams and sysfs
> > use this pattern. As a first step, and to test the migration method,
> > migrate moduleparams first.
> >
> > There are 2 "mechanical" treewide patches that are handled by Coccinelle:
> > - treewide: Convert struct kernel_param_ops initializers to DEFINE_KERNEL_PARAM_OPS
> > - treewide: Convert custom kernel_param_ops .get callbacks to seq_buf via cocci
> >
> > The last treewide patch is manual, and may need to be broken up into
> > per-subsystem patches, though I'd prefer to avoid this, as it would
> > extend the migration from 1 relase to at least 2 releases. (1 to
> > release the migration infrastructure, then 1 release to collect all the
> > subsystem changes, and possibly 1 more release to remove the migration
> > infrastructure.)
> >
> > Thoughts, questions?
>
> This looks reasonable to me. I added a few minor comments on the patches
> but they already look solid.
Thanks for the review! I'll get a v2 prepared with your notes addressed. :)
-Kees
--
Kees Cook
^ permalink raw reply
* Re: security_task_prctl: why -ENOSYS
From: Serge E. Hallyn @ 2026-06-01 19:33 UTC (permalink / raw)
To: William Roberts; +Cc: Serge E. Hallyn, Casey Schaufler, LSM, SElinux list
In-Reply-To: <CAFftDdqyTrr=wS2hUT1EvAqVsbegPRh9Y-rH5S3VEpvXbJ6QRg@mail.gmail.com>
On Mon, Jun 01, 2026 at 02:01:07PM -0500, William Roberts wrote:
> <snip>
> >
> > How about security_task_prctl_allowed()? (Mirroring security_uring_*)
> >
> > Renaming the existing hook security_task_prctl_handle() also wouldn't
> > be too bad, but that's probably more churn than it's worth.
> >
>
> Yeah if something else is already done, I'll just copy their
> convention. I went with suffix _check for now.
>
> Another possible issue that I think other upstream communities may
> have with adding an additional hook, is that there will be two hooks
> in the prctl syscall path,
> I am not sure if that's a show stopper?
It's not a hot path, so I wouldn't think so.
^ permalink raw reply
* Re: security_task_prctl: why -ENOSYS
From: William Roberts @ 2026-06-01 19:01 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Casey Schaufler, LSM, SElinux list
In-Reply-To: <ahoaFz8DMMvWgqL+@mail.hallyn.com>
<snip>
>
> How about security_task_prctl_allowed()? (Mirroring security_uring_*)
>
> Renaming the existing hook security_task_prctl_handle() also wouldn't
> be too bad, but that's probably more churn than it's worth.
>
Yeah if something else is already done, I'll just copy their
convention. I went with suffix _check for now.
Another possible issue that I think other upstream communities may
have with adding an additional hook, is that there will be two hooks
in the prctl syscall path,
I am not sure if that's a show stopper?
^ permalink raw reply
* [PATCH v5 4/4] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Yeoreum Yun @ 2026-06-01 14:27 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity
Cc: paul, zohar, roberto.sassu, noodles, jarkko, sudeep.holla,
jmorris, serge, dmitry.kasatkin, eric.snowberg, jgg, Yeoreum Yun
In-Reply-To: <20260601142749.3379697-1-yeoreum.yun@arm.com>
commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
initialises IMA at the late_initcall_sync level, so this change is no
longer required.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
index 99f1c1e5644b..025c4d4b17ca 100644
--- a/drivers/char/tpm/tpm_crb_ffa.c
+++ b/drivers/char/tpm/tpm_crb_ffa.c
@@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
*/
int tpm_crb_ffa_init(void)
{
- int ret = 0;
-
- if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
- ret = ffa_register(&tpm_crb_ffa_driver);
- if (ret) {
- tpm_crb_ffa = ERR_PTR(-ENODEV);
- return ret;
- }
- }
-
if (!tpm_crb_ffa)
- ret = -ENOENT;
+ return -ENOENT;
if (IS_ERR_VALUE(tpm_crb_ffa))
- ret = -ENODEV;
+ return -ENODEV;
- return ret;
+ return 0;
}
EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
@@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
.id_table = tpm_crb_ffa_device_id,
};
-#ifdef MODULE
module_ffa_driver(tpm_crb_ffa_driver);
-#endif
MODULE_AUTHOR("Arm");
MODULE_DESCRIPTION("TPM CRB FFA driver");
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ 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