* [GIT PULL] selinux/selinux-pr-20260615
From: Paul Moore @ 2026-06-16 2:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: selinux, linux-security-module, linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]
Linus,
A number of SELinux patches for Linux v7.2, almost all of which are
either minor fixes or hardening patches.
- Additional verifications when loading new SELinux policy
Multiple patches by Christian Göttsche to add additional validations to
the code responsible for loading and parsing SELinux policy as it is
loaded into the kernel.
- Avoid nontransitive comparisons comparisons in our sorting code
Done to prevent unexpected sorting results due to overflow. Qualys
documented a similar issue with glibc:
https://www.qualys.com/2024/01/30/qsort.txt
- Consistently use u16 for SELinux security classes
- Move from page allocations to kmalloc() based allocations
Unfortunately one of these patches had to be reverted, but you should
see a fixed version during the next merge window.
- Move from kmalloc_objs() to kzalloc_objs() in the policy load code
- Reorder sel_kill_sb() slightly to match other pseudo filesystems
- Simplify things with QSTR() instead of QSTR_INIT()
- Minor comment typo fixes
Paul
--
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
tags/selinux-pr-20260615
for you to fetch changes up to 033182baeab63ce96a6eb8aef1a6cd444fcf9519:
selinux: revert use of __getname() in selinux_genfs_get_sid()
(2026-05-29 11:24:37 -0400)
----------------------------------------------------------------
selinux/stable-7.2 PR 20260615
----------------------------------------------------------------
Christian Göttsche (9):
selinux: avoid nontransitive comparison
selinux: use u16 for security classes
selinux: more strict policy parsing
selinux: check length fields in policies
selinux: check type attr map overflows
selinux: reorder policydb_index()
selinux: beef up isvalid checks
selinux: more strict bounds check
selinux: check for simple types
Kalevi Kolttonen (2):
selinux: comment typo fix in selinuxfs.c
selinux: comment spelling fix in ibpkey.c
Mike Rapoport (Microsoft) (2):
selinux: use k[mz]alloc() to allocate temporary buffers
selinux: hooks: use __getname() to allocate path buffer
Paul Moore (1):
selinux: revert use of __getname() in selinux_genfs_get_sid()
Stephen Smalley (2):
selinux: fix sel_kill_sb()
selinux: switch two allocations to use kzalloc_objs()
Thorsten Blum (1):
selinux: use QSTR() instead of QSTR_INIT() in init_sel_fs
security/selinux/ibpkey.c | 2
security/selinux/include/security.h | 1
security/selinux/selinuxfs.c | 27 +-
security/selinux/ss/avtab.c | 49 +++
security/selinux/ss/avtab.h | 13 +
security/selinux/ss/conditional.c | 39 ++-
security/selinux/ss/constraint.h | 1
security/selinux/ss/ebitmap.c | 27 ++
security/selinux/ss/ebitmap.h | 1
security/selinux/ss/hashtab.h | 4
security/selinux/ss/mls.c | 66 +++--
security/selinux/ss/mls.h | 6
security/selinux/ss/policydb.c | 358 ++++++++++++++++++++++------
security/selinux/ss/policydb.h | 56 +++-
security/selinux/ss/services.c | 13 -
security/selinux/ss/symtab.c | 2
security/selinux/ss/symtab.h | 2
17 files changed, 512 insertions(+), 155 deletions(-)
--
paul-moore.com
^ permalink raw reply
* [GIT PULL] lsm/lsm-pr-20260615
From: Paul Moore @ 2026-06-16 2:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-security-module, linux-kernel
Linus,
A single LSM framework patch to update the security_inode_listsecurity()
hook to be able to leverage the xattr_list_one() helper function. We
wanted to do this for a while, but we needed to fixup the callers in the
NFS code first. With the NFS code changes shipping in Linux v7.0 and
no one complaining, it seemed a good time to complete the shift.
Paul
--
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git
tags/lsm-pr-20260615
for you to fetch changes up to f71ece9712b7712df98871eea9aeb60e49ca5239:
security,fs,nfs,net: update security_inode_listsecurity() interface
(2026-05-01 11:29:33 -0400)
----------------------------------------------------------------
lsm/stable-7.2 PR 20260615
----------------------------------------------------------------
Stephen Smalley (1):
security,fs,nfs,net: update security_inode_listsecurity()
interface
fs/nfs/nfs4proc.c | 7 ++-----
fs/xattr.c | 11 +++++++----
include/linux/lsm_hook_defs.h | 4 ++--
include/linux/security.h | 5 +++--
security/security.c | 16 ++++++++--------
security/selinux/hooks.c | 10 +++-------
security/smack/smack_lsm.c | 13 ++++---------
7 files changed, 29 insertions(+), 37 deletions(-)
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3] security: Expand task_setscheduler LSM hook to include CPU affinity mask
From: Paul Moore @ 2026-06-15 22:03 UTC (permalink / raw)
To: Aaron Tomlin
Cc: tsbogend, jmorris, serge, mingo, juri.lelli, vincent.guittot,
stephen.smalley.work, casey, longman, tj, hannes, mkoutny,
chenridong, dietmar.eggemann, rostedt, bsegall, mgorman, vschneid,
kprateek.nayak, omosnace, kees, neelx, sean, chjohnst, steve,
mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <exlgb3dg2kwxgna6gx2qixexvwjjul7z2ya7npal2gz4jjtr7m@h4oxgd74gsbp>
On Mon, Jun 15, 2026 at 11:22 AM Aaron Tomlin <atomlin@atomlin.com> wrote:
> On Wed, May 27, 2026 at 09:19:11PM -0400, Aaron Tomlin wrote:
> > On Wed, May 27, 2026 at 09:58:58PM +0200, Peter Zijlstra wrote:
> > > On Wed, May 27, 2026 at 01:41:52PM -0400, Aaron Tomlin wrote:
> > >
> > > > > > The actual use case here is multi-tenant workload isolation and visibility.
> > > > > > Passing the evaluated cpumask to the BPF LSM allows operators to write a
> > > > > > simple eBPF program to detect spatial boundary overlaps (e.g., logging an
> > > > > > event if a requested mask intersects with platform-reserved cores).
> > >
> > > Why isn't cgroups good enough to enforce this? If you create a cgroup
> > > hierarchy per tenant, and constrain them using the cpuset controller,
> > > they should not be able to escape, rendering this event impossible.
> >
> > Hi Peter,
> >
> > You raise a very fair point. The cpuset cgroup controller is indeed the
> > kernel's primary vehicle for spatial enforcement, and under normal
> > circumstances, it successfully prevents a tenant from escaping their
> > designated cores.
> >
> > The cpuset controller does govern resource limits, but does not audit
> > intent. When __sched_setaffinity() is invoked, the kernel compares the
> > requested in_mask against the task's allowed cpuset. If there is only a
> > partial intersection, the kernel silently truncates the requested mask to
> > fit the cpuset, without raising any alarm.
> >
> > The BPF LSM hook, conversely, receives the raw, untruncated in_mask,
> > affording operators the visibility to detect, audit, and even reject these
> > violations of intent before the kernel silently sanitises the input.
> >
> > This patch does not seek to replace the cpuset controller, but rather to
> > complement it by providing auditing capabilities.
> >
> > > > We are not creating a bespoke BPF hook here; rather, we are rectifying a
> > > > historical blind spot within the API. The existing LSM hook is invoked
> > > > during sched_setaffinity(), yet it presently receives only the task_struct
> > > > pointer. Consequently, the security module is essentially asked, "Should
> > > > Process A be permitted to alter Process B's affinity?" without being
> > > > informed of the proposed affinity itself. Providing in_mask simply
> > > > furnishes the existing hook with the requisite payload to make an informed
> > > > decision.
> > >
> > > It occurs to me that this same argument would require to also pass in
> > > the new sched_attr, no? That way the LSM can inspect the new policy
> > > before it becomes effective.
> >
> > I agree, the underlying logic does indeed extend perfectly to sched_attr.
> >
> > Presently, the LSM is equally oblivious as to whether a process is
> > requesting a benign transition to SCHED_BATCH, or attempting to escalate
> > its privileges by requesting a real-time policy such as SCHED_FIFO with
> > maximum priority. Just as with the CPU mask, providing the sched_attr
> > payload would rectify this parallel blind spot, allowing BPF policies to
> > inspect and mediate scheduling attributes before they become effective.
> >
> > If you are amenable, I should be more than happy to expand the scope of the
> > forthcoming patch to include this. Alternatively, we could address the
> > sched_attr expansion in a separate, subsequent patch. Personally, I would
> > favour the latter approach, but please do let me know your preference.
> >
> > I very much look forward to hearing Paul's thoughts on whether this aligns
> > with the broader LSM vision.
>
> Hi Paul,
>
> I am writing to politely follow up on the discussion above regarding the
> proposed enhancement to the sched_setaffinity LSM hook.
Generally speaking I wait until all dependencies land in Linus' tree.
I've lost a lot of time in the past sorting out issues only to have
one of the dependencies rejected.
> As you will see from the thread, Peter Zijlstra and I have discussed the
> architectural justification for this change. While the cpuset cgroup
> controller effectively handles spatial enforcement, it silently truncates
> requested affinity masks. Passing the raw in_mask to the LSM hook enables
> security modules (such as the BPF LSM) to audit and mediate the actual
> intent of the request before the kernel sanitises the input, a capability
> that cgroups inherently lack.
The issue of resource control comes up from time to time within the
context of LSMs, and my general comment is that we likely need to see
a more comprehensive approach to what access control on resource
limits would look like from a LSM perspective. We've seen a lot of
quick changes to solve very specific problems, but I have yet to see a
good proposal of what it would look like for a more comprehensive
approach.
There is also another issue to consider: none of the in-tree LSMs
currently use these new parameters, raising questions about their
purpose, maintainability, etc. While this is not necessarily a deal
breaker, it does go along with my comment above about taking a more
holistic view of LSM resource controls.
To summarize, I haven't thought about this too much yet because there
are other fires/patches that don't (currently) have the dependency
issues of this patch. I would also feel a lot better if there was an
in-tree user of this parameter and some discussion of how this might
fit into a more holistic approach to controlling resource limits in
the LSM subsystem.
--
paul-moore.com
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-15 20:13 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <20260615.zeinurej8oZ9@digikod.net>
On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> Hi,
>
> I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> most of them were valuable. It found issues (security or not), but it
> requires to go to https://sashiko.dev to find them, which is too easy to
> forget, and requires additional work from maintainers to copy or point
> to these reviews. I sent a PR (currently in draft) to enable email
> replies from Sashiko to the Linux Security Module mailing list (most
> patches are already reviewed anyway):
> https://github.com/sashiko-dev/sashiko/pull/278
>
> Making such reviews broadly available can improve the quality of patches
> we receive without much noise, helping for all LSM-related code. We can
> fine tune some email-related settings if needed.
>
> If there are any concern or question, this is the right time to start a
> discussion.
I recently enabled Sashiko for the SELinux list to trial it there
first, with the goal of eventually bringing this topic up for the rest
of the LSM folks on the LSM list.
While I think Sashiko's review comments are generally okay, you should
have contacted the LSM mailing list folks *before* submitting a PR
that would cause an automated bot to send email to the LSM list (this
applies to all automated emails, not just LLM reviews). Please hold
the PR until you have given people a chance to comment on the issue.
Personally, I'm okay with it.
--
paul-moore.com
^ permalink raw reply
* [PATCH] security: clarify task_prctl hook documentation
From: Bill Roberts @ 2026-06-15 20:03 UTC (permalink / raw)
To: Paul Moore, James Morris, Serge E. Hallyn
Cc: casey, Bill Roberts, linux-security-module, linux-kernel
The task_prctl hook comment incorrectly described the hook as checking
whether a prctl operation is allowed. In reality, the hook exists for
LSMs to handle LSM-specific prctl operations.
Update the function description and kernel-doc comment to reflect the
actual behavior. The old wording appears to have been copied from other
permission-check hooks despite differing semantics.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
---
security/security.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/security/security.c b/security/security.c
index 4e999f023651..96e6ef088801 100644
--- a/security/security.c
+++ b/security/security.c
@@ -3301,15 +3301,14 @@ int security_task_kill(struct task_struct *p, struct kernel_siginfo *info,
}
/**
- * security_task_prctl() - Check if a prctl op is allowed
+ * security_task_prctl() - Handle an LSM specific prctl call
* @option: operation
* @arg2: argument
* @arg3: argument
* @arg4: argument
* @arg5: argument
*
- * Check permission before performing a process control operation on the
- * current process.
+ * Handle lsm specific prctl operations.
*
* Return: Return -ENOSYS if no-one wanted to handle this op, any other value
* to cause prctl() to return immediately with that value.
--
2.54.0
^ permalink raw reply related
* Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-15 15:37 UTC (permalink / raw)
To: linux-security-module; +Cc: sashiko, Roman Gushchin, Günther Noack
Hi,
I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
most of them were valuable. It found issues (security or not), but it
requires to go to https://sashiko.dev to find them, which is too easy to
forget, and requires additional work from maintainers to copy or point
to these reviews. I sent a PR (currently in draft) to enable email
replies from Sashiko to the Linux Security Module mailing list (most
patches are already reviewed anyway):
https://github.com/sashiko-dev/sashiko/pull/278
Making such reviews broadly available can improve the quality of patches
we receive without much noise, helping for all LSM-related code. We can
fine tune some email-related settings if needed.
If there are any concern or question, this is the right time to start a
discussion.
Regards,
Mickaël
^ permalink raw reply
* Re: [PATCH v3] security: Expand task_setscheduler LSM hook to include CPU affinity mask
From: Aaron Tomlin @ 2026-06-15 15:22 UTC (permalink / raw)
To: paul
Cc: tsbogend, paul, jmorris, serge, mingo, juri.lelli,
vincent.guittot, stephen.smalley.work, casey, longman, tj, hannes,
mkoutny, chenridong, dietmar.eggemann, rostedt, bsegall, mgorman,
vschneid, kprateek.nayak, omosnace, kees, neelx, sean, chjohnst,
steve, mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <6hqq5oxvlcpmjvyns42dy2vtfvvixy7q4xyyjrrn46jrvsx5ar@gkmjsteqlpzd>
On Wed, May 27, 2026 at 09:19:11PM -0400, Aaron Tomlin wrote:
> On Wed, May 27, 2026 at 09:58:58PM +0200, Peter Zijlstra wrote:
> > On Wed, May 27, 2026 at 01:41:52PM -0400, Aaron Tomlin wrote:
> >
> > > > > The actual use case here is multi-tenant workload isolation and visibility.
> > > > > Passing the evaluated cpumask to the BPF LSM allows operators to write a
> > > > > simple eBPF program to detect spatial boundary overlaps (e.g., logging an
> > > > > event if a requested mask intersects with platform-reserved cores).
> >
> > Why isn't cgroups good enough to enforce this? If you create a cgroup
> > hierarchy per tenant, and constrain them using the cpuset controller,
> > they should not be able to escape, rendering this event impossible.
>
> Hi Peter,
>
> You raise a very fair point. The cpuset cgroup controller is indeed the
> kernel's primary vehicle for spatial enforcement, and under normal
> circumstances, it successfully prevents a tenant from escaping their
> designated cores.
>
> The cpuset controller does govern resource limits, but does not audit
> intent. When __sched_setaffinity() is invoked, the kernel compares the
> requested in_mask against the task's allowed cpuset. If there is only a
> partial intersection, the kernel silently truncates the requested mask to
> fit the cpuset, without raising any alarm.
>
> The BPF LSM hook, conversely, receives the raw, untruncated in_mask,
> affording operators the visibility to detect, audit, and even reject these
> violations of intent before the kernel silently sanitises the input.
>
> This patch does not seek to replace the cpuset controller, but rather to
> complement it by providing auditing capabilities.
>
> > > We are not creating a bespoke BPF hook here; rather, we are rectifying a
> > > historical blind spot within the API. The existing LSM hook is invoked
> > > during sched_setaffinity(), yet it presently receives only the task_struct
> > > pointer. Consequently, the security module is essentially asked, "Should
> > > Process A be permitted to alter Process B's affinity?" without being
> > > informed of the proposed affinity itself. Providing in_mask simply
> > > furnishes the existing hook with the requisite payload to make an informed
> > > decision.
> >
> > It occurs to me that this same argument would require to also pass in
> > the new sched_attr, no? That way the LSM can inspect the new policy
> > before it becomes effective.
>
> I agree, the underlying logic does indeed extend perfectly to sched_attr.
>
> Presently, the LSM is equally oblivious as to whether a process is
> requesting a benign transition to SCHED_BATCH, or attempting to escalate
> its privileges by requesting a real-time policy such as SCHED_FIFO with
> maximum priority. Just as with the CPU mask, providing the sched_attr
> payload would rectify this parallel blind spot, allowing BPF policies to
> inspect and mediate scheduling attributes before they become effective.
>
> If you are amenable, I should be more than happy to expand the scope of the
> forthcoming patch to include this. Alternatively, we could address the
> sched_attr expansion in a separate, subsequent patch. Personally, I would
> favour the latter approach, but please do let me know your preference.
>
> I very much look forward to hearing Paul's thoughts on whether this aligns
> with the broader LSM vision.
Hi Paul,
I am writing to politely follow up on the discussion above regarding the
proposed enhancement to the sched_setaffinity LSM hook.
As you will see from the thread, Peter Zijlstra and I have discussed the
architectural justification for this change. While the cpuset cgroup
controller effectively handles spatial enforcement, it silently truncates
requested affinity masks. Passing the raw in_mask to the LSM hook enables
security modules (such as the BPF LSM) to audit and mediate the actual
intent of the request before the kernel sanitises the input, a capability
that cgroups inherently lack.
Furthermore, Peter rightly observed that this reasoning extends naturally
to sched_attr. Presently, the LSM cannot inspect whether a process is
requesting a benign scheduling policy or attempting to escalate to a
real-time priority. I am entirely amenable to addressing this parallel
blind spot, preferably in a subsequent patch.
Before I proceed any further, I would be most grateful for your perspective
as the Security sub-system maintainer. Do you feel this expansion is
acceptable?
As a brief administrative aside, please note that Thomas Bogendoerfer has
already queued the MIPS-specific changes related to this work into the
mips-next tree [1][2].
I look forward to hearing your thoughts.
[1]: https://lore.kernel.org/lkml/psb6pxogv2dlknps4p3sh6rt2h7xuuxkoif6ock5vxfz2jimec@txa6iy65crtb/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=98e37db4a34d3af3fb2f4648295c25b5e40b20e3
Kind regards,
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH 2/2] keys: keyctl_pkey: replace BUG with return -EOPNOTSUPP
From: Jarkko Sakkinen @ 2026-06-15 12:06 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: dhowells, paul, jmorris, serge, kees, keyrings,
linux-security-module, linux-kernel, linux-hardening
In-Reply-To: <20260613130408.13709-3-med08elkadiri@gmail.com>
On Sat, Jun 13, 2026 at 02:04:08PM +0100, Mohammed EL Kadiri wrote:
> Replace two BUG() calls in keyctl_pkey_params_get_2() and
> keyctl_pkey_e_d_s() default cases with -EOPNOTSUPP, matching
> the error style already used in these functions.
>
> Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
> ---
> security/keys/keyctl_pkey.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
> index 97bc27bbf079..6b2821ffeb6c 100644
> --- a/security/keys/keyctl_pkey.c
> +++ b/security/keys/keyctl_pkey.c
> @@ -155,7 +155,7 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
> return -EINVAL;
> break;
> default:
> - BUG();
> + return -EOPNOTSUPP;
> }
>
> params->in_len = uparams.in_len;
> @@ -238,7 +238,8 @@ long keyctl_pkey_e_d_s(int op,
> params.op = kernel_pkey_sign;
> break;
> default:
> - BUG();
> + ret = -EOPNOTSUPP;
> + goto error_params;
> }
>
> in = memdup_user(_in, params.in_len);
> --
> 2.43.0
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Thank you.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH 1/2] keys: request_key: replace BUG with return -EINVAL
From: Jarkko Sakkinen @ 2026-06-15 12:06 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: dhowells, paul, jmorris, serge, kees, keyrings,
linux-security-module, linux-kernel, linux-hardening
In-Reply-To: <20260613130408.13709-2-med08elkadiri@gmail.com>
On Sat, Jun 13, 2026 at 02:04:07PM +0100, Mohammed EL Kadiri wrote:
> Replace BUG() in construct_get_dest_keyring() default case
> with return -EINVAL to handle the unimplemented group keyring
> destination gracefully.
>
> Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
> ---
> security/keys/request_key.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/keys/request_key.c b/security/keys/request_key.c
> index a7673ad86d18..fa2bb9f2f538 100644
> --- a/security/keys/request_key.c
> +++ b/security/keys/request_key.c
> @@ -332,7 +332,7 @@ static int construct_get_dest_keyring(struct key **_dest_keyring)
>
> case KEY_REQKEY_DEFL_GROUP_KEYRING:
> default:
> - BUG();
> + return -EINVAL;
> }
>
> /*
> --
> 2.43.0
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths
From: Jarkko Sakkinen @ 2026-06-15 11:53 UTC (permalink / raw)
To: eee sss
Cc: keyrings, linux-security-module, linux-kernel, David Howells,
Paul Moore, James Morris, Serge E. Hallyn
In-Reply-To: <CA+TOyfjifw5yiZwUmd3y7t227cTMpXxT_JNe0FSO-NYzhqE75Q@mail.gmail.com>
Awesome, no worries, great to hear, and thank you for responding.
And great collaboration :-)
BR, Jarkko
On Wed, Jun 10, 2026 at 10:21:13AM -0500, eee sss wrote:
> Thanks, Jarkko. Sorry for the delayed response.
>
> I checked the commit in for-next-keys. The updated commit message and the
> cleanup look good to me.
>
> Best,
> Shaomin
>
> On Wed, 10 Jun 2026 13:16:01 +0300, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > On Mon, Jun 08, 2026 at 08:42:21AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Jun 08, 2026 at 08:29:11AM +0300, Jarkko Sakkinen wrote:
> > > > On Mon, Jun 08, 2026 at 06:10:23AM +0300, Jarkko Sakkinen wrote:
> > > > > On Mon, Jun 08, 2026 at 06:06:21AM +0300, Jarkko Sakkinen wrote:
> > > > > > On Tue, May 26, 2026 at 10:48:38AM +0800, Shaomin Chen wrote:
> > > > > > > keyctl_instantiate_key_common() reads request_key_auth from the assumed
> > > > > > > auth key before copying an instantiation payload from userspace. The copy
> > > > > > > can fault and sleep. If the request completes and revokes the auth key in
> > > > > > > that window, the auth payload can be detached and freed before the
> > > > > > > instantiate path uses it again.
> > > > > > >
> > > > > > > A request-key helper reproducer can trigger this race. One helper child
> > > > > > > blocks in KEYCTL_INSTANTIATE_IOV while the original helper instantiates the
> > > > > > > requested key and returns. KASAN then reports a use-after-free from the
> > > > > > > stale request_key_auth payload in keyctl_instantiate_key_common().
> > > > > > >
> > > > > > > Give request_key_auth payloads a refcount. Take a payload reference while
> > > > > >
> > > > > > Please, name concrete things accurately. I.e. 'usage' in this case. If
> > > > > > you have a name, use it instead of obfuscating generalizations.
> > > > > >
> > > > > > > authkey->sem stabilizes the payload and revocation state. Hold that
> > > > > > > reference across the instantiate and reject paths. Drop the auth key
> > > > > > > owning reference from revoke and destroy.
> > > > > > >
> > > > > > > Reported-by: Shaomin Chen <eeesssooo020@gmail.com>
> > > > > > > Closes: https://lore.kernel.org/r/20260519144403.436694-1-eeesssooo020@gmail.com
> > > > > > > Signed-off-by: Shaomin Chen <eeesssooo020@gmail.com>
> > > > > > > ---
> > > > > > > include/keys/request_key_auth-type.h | 2 ++
> > > > > > > security/keys/internal.h | 2 ++
> > > > > > > security/keys/keyctl.c | 24 +++++++++++++++-----
> > > > > > > security/keys/request_key_auth.c | 33 ++++++++++++++++++++++++++--
> > > > > > > 4 files changed, 53 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > So first, couple of things.
> > > > > >
> > > > > > I'm not going to test not that well documented involving OOT driver.
> > > > >
> > > > > Oops, sorry typo. "not that well documented reproducer" :-)
> > > > >
> > > > > But it is cool we just then need to draw the picture.
> > > >
> > > > I think I got this:
> > > >
> > > > A: request_key() B: KEYCTL_INSTANTIATE_IOV
> > > > ---------------- -------------------------
> > > > create auth key
> > > > store rka in auth key
> > > > wait for helper
> > > > get auth key
> > > > load rka from auth key
> > > > copy user payload
> > > > sleep on #PF
> > > > helper completed
> > > > detach and free rka
> > > > destroy auth key
> > > > wake up
> > > > use rka->target_key
> > > > **USE-AFTER-FREE**
> > > >
> > > > So nothing really complicated here, is there?
> > >
> > > Send v2 with the code changes that I proposed as we want to the change
> > > as ergonomic as possible.
> > >
> > > Use this as the commit message:
> > >
> > > keys: Pin request_key_auth payload in instantiate paths
> > >
> > > A: request_key() B: KEYCTL_INSTANTIATE_IOV
> > > ---------------- -------------------------
> > > create auth key
> > > store rka in auth key
> > > wait for helper
> > > get auth key
> > > load rka from auth key
> > > copy user payload
> > > sleep on #PF
> > >
> > > helper completed
> > > detach and free rka
> > > destroy auth key
> > > wake up
> > > use rka->target_key
> > > **USE-AFTER-FREE**
> > >
> > > Give request_key_auth payloads a refcount. Take a payload reference while
> > > authkey->sem stabilizes the payload and revocation state. Hold that
> > > reference across the instantiate and reject paths. Drop the auth key
> > > owning reference from revoke and destroy.
> > >
> > > [jarkko: Replaced the first two paragraphs of text with a concurrency scenario.]
> > >
> > > And it includes also the remark at the end.
> > >
> > > BR, Jarkko
> >
> > Nothing heard so I pushed:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=for-next-keys&id=9feb0bb3468e863b2b82a2eabfaeec4c7c44b90c
> >
> > It has the commit message change.
> >
> > BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Jarkko Sakkinen @ 2026-06-15 11:49 UTC (permalink / raw)
To: Gary Guo
Cc: David Howells, Paul Moore, James Morris, Serge E. Hallyn,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <DJ5ES5DZ15W8.2KLL7VS1JMQOE@garyguo.net>
On Wed, Jun 10, 2026 at 02:37:41PM +0100, Gary Guo wrote:
> On Wed Jun 10, 2026 at 1:57 PM BST, Jarkko Sakkinen wrote:
> > On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
> >>
> >> This is really just for distros to be able to configure where /sbin is located.
> >> Given usr merge and (some distros) bin/sbin merge, the canonical path of
> >> request-key binary is very likely not /sbin/request-key anymore, so it seems to
> >> make sense to me to allow this to be changed rather than always go through
> >> compatibility symlinks.
> >
> > I doubt there's a huge demand other than NixOS. Just basing this on that
> > no other noise have been made so far.
>
> Just to add on this, both Fedora and openSUSE for example changes their
> CONFIG_MODPROBE_PATH to be /usr/sbin/modprobe after /usr merge. They still have
> the /sbin -> /usr/sbin symlink available, so it's not like they cannot work with
> /sbin/request-key, but I would think that if the option is available then they
> might switch to use /usr/sbin/request-key, too.
>
> After all, why would one perform a symlink walk for no reason?
>
> Best,
> Gary
It's not who is right or who is wrong. "The representation
of the argument" is not working here.
Back to the drawing board...
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 v2] evm: check return values of crypto_shash functions
From: Roberto Sassu @ 2026-06-15 7:25 UTC (permalink / raw)
To: Mimi Zohar, Daniel Hodges
Cc: roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <c1d570271884159e6c14617fa7dcd39bc2103e45.camel@linux.ibm.com>
On 3/9/2026 4:03 PM, Mimi Zohar wrote:
> On Thu, 2026-02-19 at 10:26 +0100, Roberto Sassu wrote:
>> On Thu, 2026-02-05 at 21:42 -0500, Daniel Hodges wrote:
>>> The crypto_shash_update() and crypto_shash_final() functions can fail
>>> and return error codes, but their return values were not being checked
>>> in several places in security/integrity/evm/evm_crypto.c:
>>>
>>> - hmac_add_misc() ignored returns from crypto_shash_update() and
>>> crypto_shash_final()
>>> - evm_calc_hmac_or_hash() ignored returns from crypto_shash_update()
>>> - evm_init_hmac() ignored returns from crypto_shash_update()
>>>
>>> If these hash operations fail silently, the resulting HMAC could be
>>> invalid or incomplete, which could weaken the integrity verification
>>> security that EVM provides.
>>>
>>> This patch converts hmac_add_misc() from void to int return type and
>>> adds proper error checking and propagation for all crypto_shash_*
>>> function calls. All callers are updated to handle the new return values.
>>> Additionally, error messages are logged when cryptographic operations
>>> fail to provide visibility into the failure rather than silently
>>> returning error codes.
>>>
>>> Fixes: 66dbc325afce ("evm: re-release")
>>> Signed-off-by: Daniel Hodges <git@danielhodges.dev>
>>
>> After fixing the minor issue below:
>>
>> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
>
> Thanks Daniel, Roberto. Daniel there are a couple of places where the line
> length is greater than 80. To see them, add "--max-line-length=80" to
> scripts/checkpatch.pl. I'd appreciate your fixing them. Otherwise, the patch
> looks good.
Daniel, do you have time to fix the style issues, so that we upstream
your patch?
Thanks
Roberto
^ permalink raw reply
* Re: [PATCH] lsm: hold cred_guard_mutex for lsm_set_self_attr()
From: Paul Moore @ 2026-06-14 20:25 UTC (permalink / raw)
To: John Johansen
Cc: Stephen Smalley, selinux, omosnace, casey, serge,
linux-security-module
In-Reply-To: <1c87912e-7d7c-49a9-b964-3568e63e74a0@canonical.com>
On Sat, Jun 13, 2026 at 7:29 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 5/14/26 13:47, Paul Moore wrote:
> > On May 13, 2026 Stephen Smalley <stephen.smalley.work@gmail.com> wrote:
> >>
> >> Just as proc_pid_attr_write() already does before calling the LSM
> >> hook. This only matters for SELinux and AppArmor which check
> >> whether the process is being ptraced and if so, whether to
> >> allow the transition.
> >>
> >> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> >> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
> >> ---
> >> security/lsm_syscalls.c | 9 ++++++++-
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > Thanks Stephen. I'm going to merge this into lsm/stable-7.1 now, but
> > hold on to it until next week before sending it to Linus. While I
> > can't see why John would have any objections to this, the extra time
> > should give him a chance to respond.
> >
> you would think?
> well finally getting this far back the backlog (sorry)
>
> no objections
A review is almost always better late than never ;) Thanks for taking a look.
--
paul-moore.com
^ permalink raw reply
* [PATCH] KEYS: avoid filesystem reclaim while holding keyring->sem
From: Mohammed EL Kadiri @ 2026-06-14 15:00 UTC (permalink / raw)
To: dhowells, jarkko, paul
Cc: jmorris, serge, ebiggers, keyrings, linux-security-module,
linux-kernel, stable, syzkaller-bugs, Mohammed EL Kadiri,
syzbot+f55b043dacf43776b50c
__key_link_begin() runs with keyring->sem held and calls
assoc_array_insert(), which does GFP_KERNEL allocations. Those
allocations may enter filesystem reclaim, evict an fscrypt-protected
inode, and reach keyring_clear() via fscrypt_put_master_key() --
taking a keyring semaphore of the same lockdep class and closing a
keyring->sem -> fs_reclaim -> keyring->sem cycle reported by syzbot.
Wrap the assoc_array_insert() call with memalloc_nofs_save() /
memalloc_nofs_restore() so reclaim cannot recurse into the keys
subsystem while keyring->sem is held.
Reported-by: syzbot+f55b043dacf43776b50c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
Fixes: d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key")
Cc: stable@vger.kernel.org
Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
security/keys/keyring.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index 5a9887d6b7be..21bb2e7e7cca 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -12,6 +12,7 @@
#include <linux/security.h>
#include <linux/seq_file.h>
#include <linux/err.h>
+#include <linux/sched/mm.h>
#include <linux/user_namespace.h>
#include <linux/nsproxy.h>
#include <keys/keyring-type.h>
@@ -1298,6 +1299,7 @@ int __key_link_begin(struct key *keyring,
struct assoc_array_edit **_edit)
{
struct assoc_array_edit *edit;
+ unsigned int nofs_flags;
int ret;
kenter("%d,%s,%s,",
@@ -1315,10 +1317,12 @@ int __key_link_begin(struct key *keyring,
/* Create an edit script that will insert/replace the key in the
* keyring tree.
*/
+ nofs_flags = memalloc_nofs_save();
edit = assoc_array_insert(&keyring->keys,
&keyring_assoc_array_ops,
index_key,
NULL);
+ memalloc_nofs_restore(nofs_flags);
if (IS_ERR(edit)) {
ret = PTR_ERR(edit);
goto error;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] lsm: hold cred_guard_mutex for lsm_set_self_attr()
From: John Johansen @ 2026-06-13 23:29 UTC (permalink / raw)
To: Paul Moore, Stephen Smalley, selinux
Cc: omosnace, casey, serge, linux-security-module
In-Reply-To: <b99c011e6d988fb98ad017265115b323@paul-moore.com>
On 5/14/26 13:47, Paul Moore wrote:
> On May 13, 2026 Stephen Smalley <stephen.smalley.work@gmail.com> wrote:
>>
>> Just as proc_pid_attr_write() already does before calling the LSM
>> hook. This only matters for SELinux and AppArmor which check
>> whether the process is being ptraced and if so, whether to
>> allow the transition.
>>
>> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
>> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
>> ---
>> security/lsm_syscalls.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> Thanks Stephen. I'm going to merge this into lsm/stable-7.1 now, but
> hold on to it until next week before sending it to Linus. While I
> can't see why John would have any objections to this, the extra time
> should give him a chance to respond.
>
you would think?
well finally getting this far back the backlog (sorry)
no objections
^ permalink raw reply
* Re: [PATCH v5 2/6] landlock: Add UDP send+connect access control
From: Mickaël Salaün @ 2026-06-13 20:55 UTC (permalink / raw)
To: Matthieu Buffet
Cc: Günther Noack, linux-security-module, Mikhail Ivanov,
konstantin.meskhidze, Tingmao Wang, netdev
In-Reply-To: <20260611162107.49278-3-matthieu@buffet.re>
A few issues were identified by Sashiko:
https://sashiko.dev/#/patchset/20260611162107.49278-1-matthieu%40buffet.re
I squashed this patch:
diff --git a/security/landlock/net.c b/security/landlock/net.c
index 9273cdbbf844..b12568666a9e 100644
--- a/security/landlock/net.c
+++ b/security/landlock/net.c
@@ -261,10 +261,17 @@ static int current_check_access_socket(struct socket *const sock,
static int current_check_autobind_udp_socket(struct socket *const sock)
{
+ const struct access_masks bind_udp = {
+ .net = LANDLOCK_ACCESS_NET_BIND_UDP,
+ };
struct sockaddr_storage port0 = {};
unsigned short num;
bool slow;
+ /* Quick return for non-Landlocked tasks. */
+ if (!landlock_get_applicable_subject(current_cred(), bind_udp, NULL))
+ return 0;
+
/*
* On UDP sockets, if a local port has not already been bound, calling
* connect() or sending a first datagram has the side effect of
@@ -287,8 +294,7 @@ static int current_check_autobind_udp_socket(struct socket *const sock)
port0.ss_family = READ_ONCE(sock->sk->sk_family);
return current_check_access_socket(sock, (struct sockaddr *)&port0,
- sizeof(port0),
- LANDLOCK_ACCESS_NET_BIND_UDP, false);
+ sizeof(port0), bind_udp.net, false);
}
static int hook_socket_bind(struct socket *const sock,
@@ -328,7 +334,9 @@ static int hook_socket_connect(struct socket *const sock,
* connect()ing to an AF_UNSPEC address does not trigger an autobind and
* should never be restricted.
*/
- if (ret == 0 && sk_is_udp(sock->sk) && address->sa_family != AF_UNSPEC)
+ if (ret == 0 && sk_is_udp(sock->sk) &&
+ addrlen >= offsetofend(typeof(*address), sa_family) &&
+ address->sa_family != AF_UNSPEC)
ret = current_check_autobind_udp_socket(sock);
return ret;
We might want to factor out some code, but that should be good for now.
On Thu, Jun 11, 2026 at 06:21:02PM +0200, Matthieu Buffet wrote:
> Add support for a second fine-grained UDP access right.
> LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP controls the ability to set the
> remote port of a socket (via connect()) and to specify an explicit
> destination when sending a datagram, to override any remote peer set on
> a UDP socket (e.g. in sendto() or sendmsg()).
> It will be useful for applications that send datagrams, and for some
> servers too (those creating per-client sockets, which want to receive
> traffic only from a specific address).
>
> Similarly as for bind(), this access control is performed when
> configuring sockets, not in hot code paths.
>
> Add detection of when autobind is about to be required, and deny the
> operation if the process would not be allowed to call bind(0)
> explicitly. Autobind can only be performed in udp_lib_get_port() from
> code paths already controlled by LSM hooks: when connect()ing,
> sending a first datagram, and in some splice() EOF edge case which,
> afaiu, can only happen after a remote peer has been set. This invariant
> needs to be preserved to keep bind policies actually enforced.
>
> Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
> ---
> include/uapi/linux/landlock.h | 23 ++++
> security/landlock/audit.c | 2 +
> security/landlock/limits.h | 2 +-
> security/landlock/net.c | 137 +++++++++++++++++---
> tools/testing/selftests/landlock/net_test.c | 5 +-
> 5 files changed, 151 insertions(+), 18 deletions(-)
>
> diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
> index 045b251ff1b4..b147223efc97 100644
> --- a/include/uapi/linux/landlock.h
> +++ b/include/uapi/linux/landlock.h
> @@ -378,11 +378,34 @@ struct landlock_net_port_attr {
> *
> * - %LANDLOCK_ACCESS_NET_BIND_UDP: Bind UDP sockets to the given local
> * port. Support added in Landlock ABI version 10.
> + * - %LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP: Set the remote port of UDP
> + * sockets to the given port, or send datagrams to the given remote port
> + * ignoring any destination pre-set on a socket. Support added in
> + * Landlock ABI version 10.
> + *
> + * .. note:: Setting a remote address or sending a first datagram
> + * auto-binds UDP sockets to an ephemeral local source port if not
> + * already bound. To allow this if both %LANDLOCK_ACCESS_NET_BIND_UDP
> + * and %LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP are handled, you need to
> + * either:
> + *
> + * - use a socket already bound to a port before the ruleset started
> + * being enforced;
> + * - or grant %LANDLOCK_ACCESS_NET_BIND_UDP on port 0, meaning "any
> + * port in the ephemeral port range";
> + * - or grant %LANDLOCK_ACCESS_NET_BIND_UDP on a specific port, and
> + * call :manpage:`bind(2)` on that port before trying to
> + * :manpage:`connect(2)` or send datagrams.
> + *
> + * .. note:: Sending datagrams to an ``AF_UNSPEC`` destination address
> + * family is not supported for IPv6 UDP sockets: you will need to use a
> + * ``NULL`` address instead.
> */
> /* clang-format off */
> #define LANDLOCK_ACCESS_NET_BIND_TCP (1ULL << 0)
> #define LANDLOCK_ACCESS_NET_CONNECT_TCP (1ULL << 1)
> #define LANDLOCK_ACCESS_NET_BIND_UDP (1ULL << 2)
> +#define LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP (1ULL << 3)
> /* clang-format on */
>
> /**
> diff --git a/security/landlock/audit.c b/security/landlock/audit.c
> index e676ebffeebe..851647197a01 100644
> --- a/security/landlock/audit.c
> +++ b/security/landlock/audit.c
> @@ -46,6 +46,8 @@ static const char *const net_access_strings[] = {
> [BIT_INDEX(LANDLOCK_ACCESS_NET_BIND_TCP)] = "net.bind_tcp",
> [BIT_INDEX(LANDLOCK_ACCESS_NET_CONNECT_TCP)] = "net.connect_tcp",
> [BIT_INDEX(LANDLOCK_ACCESS_NET_BIND_UDP)] = "net.bind_udp",
> + [BIT_INDEX(LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP)] =
> + "net.connect_send_udp",
> };
>
> static_assert(ARRAY_SIZE(net_access_strings) == LANDLOCK_NUM_ACCESS_NET);
> diff --git a/security/landlock/limits.h b/security/landlock/limits.h
> index c0f30a4591b8..a4d908b240a2 100644
> --- a/security/landlock/limits.h
> +++ b/security/landlock/limits.h
> @@ -23,7 +23,7 @@
> #define LANDLOCK_MASK_ACCESS_FS ((LANDLOCK_LAST_ACCESS_FS << 1) - 1)
> #define LANDLOCK_NUM_ACCESS_FS __const_hweight64(LANDLOCK_MASK_ACCESS_FS)
>
> -#define LANDLOCK_LAST_ACCESS_NET LANDLOCK_ACCESS_NET_BIND_UDP
> +#define LANDLOCK_LAST_ACCESS_NET LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP
> #define LANDLOCK_MASK_ACCESS_NET ((LANDLOCK_LAST_ACCESS_NET << 1) - 1)
> #define LANDLOCK_NUM_ACCESS_NET __const_hweight64(LANDLOCK_MASK_ACCESS_NET)
>
> diff --git a/security/landlock/net.c b/security/landlock/net.c
> index 8da40614c452..0e697403eca9 100644
> --- a/security/landlock/net.c
> +++ b/security/landlock/net.c
> @@ -44,7 +44,8 @@ int landlock_append_net_rule(struct landlock_ruleset *const ruleset,
> static int current_check_access_socket(struct socket *const sock,
> struct sockaddr *const address,
> const int addrlen,
> - access_mask_t access_request)
> + access_mask_t access_request,
> + bool connecting)
> {
> unsigned short sock_family;
> __be16 port;
> @@ -75,19 +76,51 @@ static int current_check_access_socket(struct socket *const sock,
>
> switch (address->sa_family) {
> case AF_UNSPEC:
> - if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP) {
> + if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP ||
> + (access_request == LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP &&
> + connecting)) {
> /*
> * Connecting to an address with AF_UNSPEC dissolves
> - * the TCP association, which have the same effect as
> - * closing the connection while retaining the socket
> - * object (i.e., the file descriptor). As for dropping
> - * privileges, closing connections is always allowed.
> - *
> - * For a TCP access control system, this request is
> - * legitimate. Let the network stack handle potential
> + * the remote association while retaining the socket
> + * object (i.e., the file descriptor). For TCP, it has
> + * the same effect as closing the connection. For UDP,
> + * it removes any preset remote address. As for
> + * dropping privileges, these actions are always
> + * allowed.
> + * Let the network stack handle potential
> * inconsistencies and return -EINVAL if needed.
> */
> return 0;
> + } else if (access_request ==
> + LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP) {
> + if (sock_family == AF_INET6) {
> + /*
> + * We cannot allow sending UDP datagrams to an
> + * explicit AF_UNSPEC address on IPv6 sockets,
> + * even if AF_UNSPEC is treated as "no address"
> + * on such sockets (so it should always be allowed).
> + * That's because the socket's family can change under
> + * our feet (if another thread calls setsockopt(IPV6_ADDRFORM))
> + * to IPv4, which would then treat AF_UNSPEC as
> + * AF_INET.
> + */
> + audit_net.family = AF_UNSPEC;
> + audit_net.sk = sock->sk;
> + landlock_init_layer_masks(
> + subject->domain, access_request,
> + &layer_masks, LANDLOCK_KEY_NET_PORT);
> + landlock_log_denial(
> + subject,
> + &(struct landlock_request){
> + .type = LANDLOCK_REQUEST_NET_ACCESS,
> + .audit.type =
> + LSM_AUDIT_DATA_NET,
> + .audit.u.net = &audit_net,
> + .access = access_request,
> + .layer_masks = &layer_masks,
> + });
> + return -EACCES;
> + }
> } else if (access_request == LANDLOCK_ACCESS_NET_BIND_TCP ||
> access_request == LANDLOCK_ACCESS_NET_BIND_UDP) {
> /*
> @@ -130,7 +163,11 @@ static int current_check_access_socket(struct socket *const sock,
> } else {
> WARN_ON_ONCE(1);
> }
> - /* Only for bind(AF_UNSPEC+INADDR_ANY) on IPv4 socket. */
> + /*
> + * AF_UNSPEC is treated as AF_INET only in
> + * bind(AF_UNSPEC+INADDR_ANY) on IPv4 sockets and
> + * when sending to AF_UNSPEC addresses on IPv4 sockets.
> + */
> fallthrough;
> case AF_INET: {
> const struct sockaddr_in *addr4;
> @@ -141,7 +178,8 @@ static int current_check_access_socket(struct socket *const sock,
> addr4 = (struct sockaddr_in *)address;
> port = addr4->sin_port;
>
> - if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP) {
> + if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP ||
> + access_request == LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP) {
> audit_net.dport = port;
> audit_net.v4info.daddr = addr4->sin_addr.s_addr;
> } else if (access_request == LANDLOCK_ACCESS_NET_BIND_TCP ||
> @@ -164,7 +202,8 @@ static int current_check_access_socket(struct socket *const sock,
> addr6 = (struct sockaddr_in6 *)address;
> port = addr6->sin6_port;
>
> - if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP) {
> + if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP ||
> + access_request == LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP) {
> audit_net.dport = port;
> audit_net.v6info.daddr = addr6->sin6_addr;
> } else if (access_request == LANDLOCK_ACCESS_NET_BIND_TCP ||
> @@ -221,6 +260,38 @@ static int current_check_access_socket(struct socket *const sock,
> return -EACCES;
> }
>
> +static int current_check_autobind_udp_socket(struct socket *const sock)
> +{
> + struct sockaddr_storage port0 = {};
> + unsigned short num;
> + bool slow;
> +
> + /*
> + * On UDP sockets, if a local port has not already been bound,
> + * calling connect() or sending a first datagram has the side
> + * effect of autobinding an ephemeral port: we also have to check
> + * that the process would have had the right to bind(0) explicitly.
> + * Hold the socket lock around the inet_num read to exclude
> + * udp_lib_get_port()'s transient inet_num = snum write that is
> + * reverted to 0 on a failing reuseport bind.
> + */
> + slow = lock_sock_fast(sock->sk);
> + num = inet_sk(sock->sk)->inet_num;
> + unlock_sock_fast(sock->sk, slow);
> + if (num != 0)
> + return 0;
> +
> + /*
> + * Construct a struct sockaddr* with port 0 to pretend the
> + * process tried to bind() on that address.
> + */
> + port0.ss_family = READ_ONCE(sock->sk->sk_family);
> +
> + return current_check_access_socket(sock, (struct sockaddr *)&port0,
> + sizeof(port0),
> + LANDLOCK_ACCESS_NET_BIND_UDP, false);
> +}
> +
> static int hook_socket_bind(struct socket *const sock,
> struct sockaddr *const address, const int addrlen)
> {
> @@ -234,7 +305,7 @@ static int hook_socket_bind(struct socket *const sock,
> return 0;
>
> return current_check_access_socket(sock, address, addrlen,
> - access_request);
> + access_request, false);
> }
>
> static int hook_socket_connect(struct socket *const sock,
> @@ -242,19 +313,55 @@ static int hook_socket_connect(struct socket *const sock,
> const int addrlen)
> {
> access_mask_t access_request;
> + int ret = 0;
>
> if (sk_is_tcp(sock->sk))
> access_request = LANDLOCK_ACCESS_NET_CONNECT_TCP;
> + else if (sk_is_udp(sock->sk))
> + access_request = LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP;
> else
> return 0;
>
> - return current_check_access_socket(sock, address, addrlen,
> - access_request);
> + ret = current_check_access_socket(sock, address, addrlen,
> + access_request, true);
> +
> + /*
> + * connect()ing to an AF_UNSPEC address does not trigger an
> + * autobind and should never be restricted.
> + */
> + if (ret == 0 && sk_is_udp(sock->sk) && address->sa_family != AF_UNSPEC)
> + ret = current_check_autobind_udp_socket(sock);
> +
> + return ret;
> +}
> +
> +static int hook_socket_sendmsg(struct socket *const sock,
> + struct msghdr *const msg, const int size)
> +{
> + struct sockaddr *const address = msg->msg_name;
> + const int addrlen = msg->msg_namelen;
> + access_mask_t access_request;
> + int ret = 0;
> +
> + if (sk_is_udp(sock->sk))
> + access_request = LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP;
> + else
> + return 0;
> +
> + if (address != NULL)
> + ret = current_check_access_socket(sock, address, addrlen,
> + access_request, false);
> +
> + if (ret == 0)
> + ret = current_check_autobind_udp_socket(sock);
> +
> + return ret;
> }
>
> static struct security_hook_list landlock_hooks[] __ro_after_init = {
> LSM_HOOK_INIT(socket_bind, hook_socket_bind),
> LSM_HOOK_INIT(socket_connect, hook_socket_connect),
> + LSM_HOOK_INIT(socket_sendmsg, hook_socket_sendmsg),
> };
>
> __init void landlock_add_net_hooks(void)
> diff --git a/tools/testing/selftests/landlock/net_test.c b/tools/testing/selftests/landlock/net_test.c
> index ec392d971ea3..016c7277e370 100644
> --- a/tools/testing/selftests/landlock/net_test.c
> +++ b/tools/testing/selftests/landlock/net_test.c
> @@ -1326,12 +1326,13 @@ FIXTURE_TEARDOWN(mini)
>
> /* clang-format off */
>
> -#define ACCESS_LAST LANDLOCK_ACCESS_NET_BIND_UDP
> +#define ACCESS_LAST LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP
>
> #define ACCESS_ALL ( \
> LANDLOCK_ACCESS_NET_BIND_TCP | \
> LANDLOCK_ACCESS_NET_CONNECT_TCP | \
> - LANDLOCK_ACCESS_NET_BIND_UDP)
> + LANDLOCK_ACCESS_NET_BIND_UDP | \
> + LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP)
>
> /* clang-format on */
>
> --
> 2.47.3
>
>
^ permalink raw reply related
* Re: [PATCH] Add LoadPin support for eBPF program loading
From: Alex Roberts @ 2026-06-13 18:59 UTC (permalink / raw)
To: Alexei Starovoitov, David Windsor
Cc: Kees Cook, Paul Moore, James Morris, Serge E . Hallyn, LKML,
LSM List, bpf, Alexei Starovoitov, KP Singh
In-Reply-To: <CAADnVQL9CJMY9h8haj5+99x-0GmiaHv3wDWuZ_YCYETKTznBbw@mail.gmail.com>
>This patch is pointless.
This was supposed to an RFC, but b4 complained when adding presubject "[RFC]".
Sorry about the bot build errors, tested against WSL config. Is there a standard config to build against for patches?
>- [High] The LoadPin eBPF trust mechanism can be trivially bypassed
>using standard system interpreters like the dynamic linker (`ld.so`).
>- [High] The LoadPin eBPF trust mechanism can be bypassed by a
>privileged attacker using prctl(PR_SET_MM_EXE_FILE).
As the intent was an RFC, is there any value in pursuing LoadPin for eBPF or is it so trivially bypassable its not worth it?
________________________________________
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Sent: Friday, June 12, 2026 10:20 AM
To: David Windsor <dwindsor@gmail.com>
Cc: alex.roberts109@outlook.com <alex.roberts109@outlook.com>; Kees Cook <kees@kernel.org>; Paul Moore <paul@paul-moore.com>; James Morris <jmorris@namei.org>; Serge E . Hallyn <serge@hallyn.com>; LKML <linux-kernel@vger.kernel.org>; LSM List <linux-security-module@vger.kernel.org>; bpf <bpf@vger.kernel.org>; Alexei Starovoitov <ast@kernel.org>; KP Singh <kpsingh@kernel.org>
Subject: Re: [PATCH] Add LoadPin support for eBPF program loading
On Thu, Jun 11, 2026 at 5:08 PM David Windsor <dwindsor@gmail.com> wrote:
>
> On Thu, Jun 11, 2026 at 01:59:10PM -0500, Alex Roberts wrote:
> > +static int loadpin_bpf_prog_load(struct bpf_prog *prog, union bpf_attr *attr,
> > + struct bpf_token *token, bool is_kernel)
> > +{
> > + int res = 0;
> > + struct file *exe_file = NULL;
> > + struct mm_struct *mm = current->mm;
> > +
> > + if (is_kernel || !mm)
> > + return 0;
> > +
> > + exe_file = get_mm_exe_file(mm);
> > + if (!exe_file)
> > + return 0;
> > +
> > + res = loadpin_check(exe_file, READING_EBPF);
>
> Why are we checking current here? IIUC this will be whoever calls
> bpf(2), which would be the loader, which would then be able to load bpf
> programs from an untrusted source.
>
> In the kmod case loadpin_check() sees the .ko itself.
See sashiko comments:
- [High] The LoadPin eBPF trust mechanism can be trivially bypassed
using standard system interpreters like the dynamic linker (`ld.so`).
- [High] The LoadPin eBPF trust mechanism can be bypassed by a
privileged attacker using prctl(PR_SET_MM_EXE_FILE).
and the bot is correct.
This patch is pointless.
^ permalink raw reply
* Re: [PATCH] Add LoadPin support for eBPF program loading
From: Alex Roberts @ 2026-06-13 18:54 UTC (permalink / raw)
To: Alexei Starovoitov, David Windsor
Cc: Kees Cook, Paul Moore, James Morris, Serge E . Hallyn, LKML,
LSM List, bpf, Alexei Starovoitov, KP Singh
In-Reply-To: <CAADnVQL9CJMY9h8haj5+99x-0GmiaHv3wDWuZ_YCYETKTznBbw@mail.gmail.com>
>Why are we checking current here? IIUC this will be whoever calls
bpf(2), which would be the loader, which would then be able to load bpf
programs from an untrusted source.
The loader's filesystem would be pinned. If the filesystem is trusted, e.g., dm-verity with signed root hash, the loader is implicitly trusted. Would this not be similar unsigned kmodules from a load-pinned dm-verity filesystem?
Obviously, this would have to exclude the usecase of dynamically generated BPF programs from bpftrace.
________________________________________
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Sent: Friday, June 12, 2026 10:20 AM
To: David Windsor <dwindsor@gmail.com>
Cc: alex.roberts109@outlook.com <alex.roberts109@outlook.com>; Kees Cook <kees@kernel.org>; Paul Moore <paul@paul-moore.com>; James Morris <jmorris@namei.org>; Serge E . Hallyn <serge@hallyn.com>; LKML <linux-kernel@vger.kernel.org>; LSM List <linux-security-module@vger.kernel.org>; bpf <bpf@vger.kernel.org>; Alexei Starovoitov <ast@kernel.org>; KP Singh <kpsingh@kernel.org>
Subject: Re: [PATCH] Add LoadPin support for eBPF program loading
On Thu, Jun 11, 2026 at 5:08 PM David Windsor <dwindsor@gmail.com> wrote:
>
> On Thu, Jun 11, 2026 at 01:59:10PM -0500, Alex Roberts wrote:
> > +static int loadpin_bpf_prog_load(struct bpf_prog *prog, union bpf_attr *attr,
> > + struct bpf_token *token, bool is_kernel)
> > +{
> > + int res = 0;
> > + struct file *exe_file = NULL;
> > + struct mm_struct *mm = current->mm;
> > +
> > + if (is_kernel || !mm)
> > + return 0;
> > +
> > + exe_file = get_mm_exe_file(mm);
> > + if (!exe_file)
> > + return 0;
> > +
> > + res = loadpin_check(exe_file, READING_EBPF);
>
> Why are we checking current here? IIUC this will be whoever calls
> bpf(2), which would be the loader, which would then be able to load bpf
> programs from an untrusted source.
>
> In the kmod case loadpin_check() sees the .ko itself.
See sashiko comments:
- [High] The LoadPin eBPF trust mechanism can be trivially bypassed
using standard system interpreters like the dynamic linker (`ld.so`).
- [High] The LoadPin eBPF trust mechanism can be bypassed by a
privileged attacker using prctl(PR_SET_MM_EXE_FILE).
and the bot is correct.
This patch is pointless.
^ permalink raw reply
* Re: [PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
From: Yan Zhu @ 2026-06-13 15:08 UTC (permalink / raw)
To: Fan Wu
Cc: alexs, si.yanteng, corbet, mic, dzm91, skhan, gnoack, linux-doc,
linux-security-module
In-Reply-To: <CAKtyLkE3unhxMsH1LpqvjHQoKVgz1tcTsZWUxNHs+R6v2amf6w@mail.gmail.com>
On 6/13/2026 10:54 AM, Fan Wu wrote:
> On Fri, Jun 12, 2026 at 8:59 AM Yan Zhu <zhuyan2015@qq.com> wrote:
>>
>> Translate Documentation/admin-guide/LSM/ipe.rst into Chinese.
>>
>> Update the translation through commit d7ba853c0e47
>> ("ipe: Update documentation for script enforcement")
>>
>> Assisted-by: Claude:deepseek-4-pro
>> Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
>> ---
>
> Have you tried to refine the AI translation? IMO some are really bad translated.
I have double-checked it several times and manually corrected the
formatting and the accuracy of the translation.
>
> Also how does the doc translation project work? I do notice there is
> another IPE design doc translation,
> https://docs.kernel.org/next/translations/zh_CN/security/ipe.html
> which has a wrong "original link".>
> -Fan
The documents in the "admin-guide" directory are intended for both
administrators and users, focusing on usage; the documents in the
"security" directory are targeted at developers, emphasizing design and
development.
--
Thanks
Yan Zhu
^ permalink raw reply
* [PATCH 2/2] keys: keyctl_pkey: replace BUG with return -EOPNOTSUPP
From: Mohammed EL Kadiri @ 2026-06-13 13:04 UTC (permalink / raw)
To: jarkko, dhowells
Cc: paul, jmorris, serge, kees, keyrings, linux-security-module,
linux-kernel, linux-hardening, Mohammed EL Kadiri
In-Reply-To: <20260613130408.13709-1-med08elkadiri@gmail.com>
Replace two BUG() calls in keyctl_pkey_params_get_2() and
keyctl_pkey_e_d_s() default cases with -EOPNOTSUPP, matching
the error style already used in these functions.
Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
security/keys/keyctl_pkey.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
index 97bc27bbf079..6b2821ffeb6c 100644
--- a/security/keys/keyctl_pkey.c
+++ b/security/keys/keyctl_pkey.c
@@ -155,7 +155,7 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
return -EINVAL;
break;
default:
- BUG();
+ return -EOPNOTSUPP;
}
params->in_len = uparams.in_len;
@@ -238,7 +238,8 @@ long keyctl_pkey_e_d_s(int op,
params.op = kernel_pkey_sign;
break;
default:
- BUG();
+ ret = -EOPNOTSUPP;
+ goto error_params;
}
in = memdup_user(_in, params.in_len);
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] keys: request_key: replace BUG with return -EINVAL
From: Mohammed EL Kadiri @ 2026-06-13 13:04 UTC (permalink / raw)
To: jarkko, dhowells
Cc: paul, jmorris, serge, kees, keyrings, linux-security-module,
linux-kernel, linux-hardening, Mohammed EL Kadiri
In-Reply-To: <20260613130408.13709-1-med08elkadiri@gmail.com>
Replace BUG() in construct_get_dest_keyring() default case
with return -EINVAL to handle the unimplemented group keyring
destination gracefully.
Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
security/keys/request_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index a7673ad86d18..fa2bb9f2f538 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -332,7 +332,7 @@ static int construct_get_dest_keyring(struct key **_dest_keyring)
case KEY_REQKEY_DEFL_GROUP_KEYRING:
default:
- BUG();
+ return -EINVAL;
}
/*
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] security/keys: replace BUG() in unreachable default cases
From: Mohammed EL Kadiri @ 2026-06-13 13:04 UTC (permalink / raw)
To: jarkko, dhowells
Cc: paul, jmorris, serge, kees, keyrings, linux-security-module,
linux-kernel, linux-hardening, Mohammed EL Kadiri
Replace BUG() in two switch default cases with proper error
returns.
Mohammed EL Kadiri (2):
keys: request_key: replace BUG with return -EINVAL
keys: keyctl_pkey: replace BUG with return -EOPNOTSUPP
security/keys/keyctl_pkey.c | 5 +++--
security/keys/request_key.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH] apparmor: fix use-after-free in policy replacement path
From: John Johansen @ 2026-06-13 9:42 UTC (permalink / raw)
To: Junxiao Chang, paul, jmorris, serge, apparmor,
linux-security-module, linux-kernel
In-Reply-To: <20260613060424.2213712-1-junxiao.chang@intel.com>
On 6/12/26 23:04, Junxiao Chang wrote:
> A use-after-free issue can be triggered when running the
> following stress-ng workload:
>
> ```
> sudo stress-ng --apparmor 0 --timeout 30 \
> --oom-avoid-bytes 10% --skip-silent --verbose
> ```
>
> The warning looks like:
>
> ```
> refcount_t: addition on 0; use-after-free
> aa_replace_profiles+0xbe5/0x12a0
> policy_update+0xdb/0x170
> profile_replace+0x4b/0xb0
> ```
>
> The issue can be reproduced on both v7.1-rc7 and Ubuntu
> 6.17.0-35-generic kernels.
>
> aa_get_profile_loaddata() requires the supplied loaddata object
> to hold a valid reference. However, the loaddata reference count
> may already have reached zero in the replacement loop, resulting
> in a use-after-free condition.
>
> Avoid calling aa_get_profile_loaddata() on loaddata objects with
> a zero reference count and skip those entries instead.
>
> Fixes: a0b7091c4de4 ("apparmor: fix race on rawdata dereference")
> Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
sorry I went with Ruslan Valiyev's earlier patch that fixes the same
issue
apparmor: fix use-after-free in rawdata dedup loop
> ---
> security/apparmor/policy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/apparmor/policy.c b/security/apparmor/policy.c
> index b6a5eb4021dbd..98f84d4552697 100644
> --- a/security/apparmor/policy.c
> +++ b/security/apparmor/policy.c
> @@ -1220,7 +1220,7 @@ ssize_t aa_replace_profiles(struct aa_ns *policy_ns, struct aa_label *label,
> /* check for duplicate rawdata blobs: space and file dedup */
> if (!list_empty(&ns->rawdata_list)) {
> list_for_each_entry(rawdata_ent, &ns->rawdata_list, list) {
> - if (aa_rawdata_eq(rawdata_ent, udata)) {
> + if (kref_read(&rawdata_ent->pcount) && aa_rawdata_eq(rawdata_ent, udata)) {
> struct aa_loaddata *tmp;
>
> tmp = aa_get_profile_loaddata(rawdata_ent);
^ permalink raw reply
* Re: [PATCH 1/3] apparmor: Fix return in ns_mkdir_op
From: John Johansen @ 2026-06-13 7:13 UTC (permalink / raw)
To: Hongling Zeng, paul, jmorris, serge, neil, brauner, jlayton, jack
Cc: apparmor, linux-security-module, linux-kernel, zhongling0719
In-Reply-To: <20260503041243.200895-1-zenghongling@kylinos.cn>
On 5/2/26 21:12, Hongling Zeng wrote:
> Return NULL instead of passing to ERR_PTR while error is zero.
> Fixes smatch warning:
> - security/apparmor/apparmorfs.c:1846 ns_mkdir_op() warn:
> passing zero to 'ERR_PTR'
>
> Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Acked-by: John Johansen <john.johansen@canonical.com>
this has been pulled in to my tree
> ---
> security/apparmor/apparmorfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
> index ededaf46f3ca..1d7b1c70f22a 100644
> --- a/security/apparmor/apparmorfs.c
> +++ b/security/apparmor/apparmorfs.c
> @@ -1922,7 +1922,7 @@ static struct dentry *ns_mkdir_op(struct mnt_idmap *idmap, struct inode *dir,
> mutex_unlock(&parent->lock);
> aa_put_ns(parent);
>
> - return ERR_PTR(error);
> + return error ? ERR_PTR(error) : NULL;
> }
>
> static int ns_rmdir_op(struct inode *dir, struct dentry *dentry)
^ permalink raw reply
* Re: [PATCH] apparmor/lsm: Fix aa_dfa_unpack's error handling in aa_setup_dfa_engine
From: John Johansen @ 2026-06-13 4:42 UTC (permalink / raw)
To: GONG Ruiqi, Paul Moore, James Morris, Serge E . Hallyn,
Georgia Garcia
Cc: apparmor, linux-security-module, linux-kernel, lujialin4,
zhaoyipeng5
In-Reply-To: <20260423031056.563527-1-gongruiqi1@huawei.com>
On 4/22/26 20:10, GONG Ruiqi wrote:
> aa_dfa_unpack returns ERR_PTR not NULL when it fails, but aa_put_dfa
> only checks NULL for its input, which would cause invalid memory access
> in aa_put_dfa. Set nulldfa to NULL explicitly to fix that.
>
> Fixes: 98b824ff8984 ("apparmor: refcount the pdb")
> Signed-off-by: GONG Ruiqi <gongruiqi1@huawei.com>
sorry for the lateness of the reply my mail wasn't working when I pulled
this in for 7.1
Acked-by: John Johansen <john.johansen@canonical.com>
> ---
> security/apparmor/lsm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index c1d42fc72fdb..ead2f07982b6 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -2465,6 +2465,7 @@ static int __init aa_setup_dfa_engine(void)
> TO_ACCEPT2_FLAG(YYTD_DATA32));
> if (IS_ERR(nulldfa)) {
> error = PTR_ERR(nulldfa);
> + nulldfa = NULL;
> goto fail;
> }
> nullpdb->dfa = aa_get_dfa(nulldfa);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox