* Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Jens Axboe @ 2026-06-17 14:56 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Bryam Vargas, Günther Noack, Paul Moore, Keith Busch,
Christoph Hellwig, Sagi Grimberg, linux-security-module,
Tingmao Wang
In-Reply-To: <20260617.aeNg7Aeseez4@digikod.net>
On 6/17/26 8:16 AM, Micka?l Sala?n wrote:
> On Tue, Jun 16, 2026 at 08:44:55PM -0600, Jens Axboe wrote:
>> On 6/16/26 8:25 PM, Bryam Vargas wrote:
>>> Thanks Jens ? noted, the fix belongs in Landlock. Micka?l has the full
>>> report.
>>
>> Indeed - and hence no need to bother anyone else with it by blasting it
>> wide. I've already explained this multiple times, but on the private
>> security list, when the occasional AI report comes in on things like
>> this. Hence why it's a bit tiring to see the same stuff come across,
>> once again.
>>
>> For the landlock folks, I'd suggest taking a look at what hooks already
>> exists (and existed, when landlock was merged) for selinux etc, that'd
>> be a really good hint on the existing surface covered.
>
> As I explained in previous (private) reports, there is currently no
> io_uring hooks implemented for Landlock because there is no use for
> them.
>
> io_uring "bypass" was already mentioned to us two times in March but
> io_uring personality credential is not a Landlock bypass. The Landlock
> threat model is about enforcing restrictions when accessing new kernel
> resources, on a sandboxed subject. The credential identifies a set of
> access rights, so in the case of io_uring, the subject is inherited by
> the io_uring personality (i.e. the file descriptor). If a sandboxed
> task creates an io_uring personality, it will be sandboxed with the same
> restrictions, which is BTW an interesting property (e.g. pass a
> restricted io_uring FD to processes)
>
> A sandboxed process cannot create an io_uring personality that would
> bypass its own restrictions, so there is no Landlock bypass. Inheriting
> or receiving a file descriptor is not restricted by Landlock because
> these are operations from outside (or before) the sandbox. If we want
> to restrict them, we need to restrict the processes creating such file
> descriptor.
>
> Inherited or passed file descriptors are outside the Landlock threat
> model because Landlock is only one part of the security policy when
> (willingly) interacting with other processes. In a nutshell, it's the
> security capability model (where an object has some associated rights).
> For instance, if a process willingly passes a file descriptor tied to a
> secret file, then the receiving side can (and should be able to) read
> it, being sandboxed with Landlock or not. The scope of Landlock is to
> drop ambient rights, but if an *unsandboxed* process is OK to pass a
> sensitive resource, then that's a security architecture issue (i.e. a
> confused deputy attack).
>
> A nice side effect of this approach is that a process can sandbox itself
> with a specific Landlock security policy and create an io_uring file
> descriptor that will inherit the Landlock restrictions. It can then
> pass this FD to other processes with the guarantee that this FD will
> only give access to resources allowed by the Landlock policy.
>
> Landlock could implement the security_uring_sqpoll() hook, but for now
> the use case is not clear to me. We are working on controling socket
> creation according to they properties and I think the same approach
> would be useful for IO_URING:
> https://lore.kernel.org/r/20251118134639.3314803-1-ivanov.mikhail1@huawei-partners.com
>
> I agree that this might be confusing and I plan to improve Landlock
> documentation to make this clear and simpler for AI to take into
> account.
I think updating the documentation is a good idea. Most of these are AI
nonsense anyway, and it'd hopefully help if the documentation reflected
what you wrote above. Even if not, then at least when the next one of
these slop reports come in, the reply can be as simple as just linking
to the documentation.
> BTW, we also have an opened issue to add io_uring tests:
> https://github.com/landlock-lsm/linux/issues/23
Nice!
--
Jens Axboe
^ permalink raw reply
* Re: Landlock: LANDLOCK_ACCESS_NET_CONNECT_TCP bypass via TCP Fast Open
From: Mickaël Salaün @ 2026-06-17 14:22 UTC (permalink / raw)
To: Bryam Vargas
Cc: Günther Noack, Matthieu Buffet, Paul Moore, Eric Dumazet,
Neal Cardwell, linux-security-module, netdev, linux-kernel,
Mikhail Ivanov
In-Reply-To: <20260616201615.275032-1-hexlabsecurity@proton.me>
Hi,
Thanks for the report. This was previously identified by Mikhail and
Matthieu, see the related issue:
https://github.com/landlock-lsm/linux/issues/41
On Tue, Jun 16, 2026 at 08:16:22PM +0000, Bryam Vargas wrote:
> Hello Mickaël, and Landlock folks,
>
> A task confined by a Landlock ruleset that handles
> LANDLOCK_ACCESS_NET_CONNECT_TCP and is denied connecting to a given port can
> still establish a TCP connection to that port by using TCP Fast Open, i.e.
> sendto(fd, ..., MSG_FASTOPEN, &dst, dstlen) on a fresh stream socket. The
> network-egress confinement for TCP connect is silently bypassed.
>
> Affected
> --------
> Any kernel with CONFIG_SECURITY_LANDLOCK=y and Landlock enabled that supports
> the TCP network access rights (Landlock ABI >= 4, since Linux 6.7). Confirmed by
> source inspection on mainline (v7.1-rc7) and reproduced on Linux 7.0.11
> (Landlock ABI 8). No CONFIG beyond Landlock + IPv4/IPv6 TCP; TCP Fast Open client
> is enabled by the per-netns default (net.ipv4.tcp_fastopen has TFO_CLIENT_ENABLE
> set), so no sysctl change and no setsockopt are required.
>
> Root cause
> ----------
> LANDLOCK_ACCESS_NET_CONNECT_TCP is enforced only by the socket_connect LSM hook
> (hook_socket_connect -> current_check_access_socket). security_socket_connect()
> has exactly one call site in the tree, net/socket.c (the connect(2) syscall).
>
> TCP Fast Open performs an implicit connect inside sendmsg:
>
> tcp_sendmsg_locked() net/ipv4/tcp.c (MSG_FASTOPEN branch)
> -> tcp_sendmsg_fastopen() net/ipv4/tcp.c
> -> __inet_stream_connect(..., is_sendmsg=1) net/ipv4/af_inet.c
> -> sk->sk_prot->connect() net/ipv4/af_inet.c -> tcp_v4_connect()
>
> This path establishes the connection to the address taken from msg_name but
> never calls security_socket_connect(). The only LSM hook fired on the sendmsg
> path is security_socket_sendmsg(), and Landlock registers no socket_sendmsg
> hook, so LANDLOCK_ACCESS_NET_CONNECT_TCP is never re-checked. __inet_stream_connect()
> itself carries no LSM hook (only the cgroup-BPF pre_connect, a different
> mechanism).
>
> Notably the kernel already mediates the analogous AF_UNIX implicit-connect on the
> send path via the unix_may_send hook, which Landlock does register
> (hook_unix_may_send) -- so the sendmsg-implies-connect pattern is recognized, but
> the TCP Fast Open case has no equivalent coverage. The MPTCP fast-open path
> (mptcp_sendmsg_fastopen -> __inet_stream_connect) is a second producer of the
> same unmediated connect (by source inspection; not separately reproduced).
>
> Reproducer
> ----------
> A self-contained, fully unprivileged PoC is available on request. It forks an
> unconfined TFO-capable loopback listener, then in a child applies a Landlock
> ruleset handling LANDLOCK_ACCESS_NET_CONNECT_TCP with no allow rule
> (landlock_create_ruleset() with handled_access_net =
> LANDLOCK_ACCESS_NET_CONNECT_TCP, no landlock_add_rule(), then
> landlock_restrict_self(); every TCP connect is denied) and tries the forbidden
> port two ways:
>
> (1) connect(fd, &dst) -> -EACCES (Landlock enforces CONNECT_TCP)
> (2) sendto(fd2, buf, len, MSG_FASTOPEN, &dst, dstlen)
> -> succeeds; the listener accepts the
> connection and reads the payload.
>
> Observed on Linux 7.0.11 (Landlock ABI 8):
>
> [1] connect(2) -> ret=-1 errno=13 (Permission denied)
> [2] sendto(MSG_FASTOPEN) -> ret=14 errno=0 (OK/queued)
> [+] listener ACCEPTED the confined child's connection; payload="..."
>
> connect(2) to the port is denied while sendto(MSG_FASTOPEN) reaches the identical
> port and delivers data.
>
> Impact
> ------
> A sandbox that uses LANDLOCK_ACCESS_NET_CONNECT_TCP to restrict outbound TCP
> (e.g. to keep a confined component from reaching an internal service or a
> metadata endpoint) can be escaped by an unprivileged, self-confined task with no
> CAP and no namespace transition -- for any destination port, since the
> implicit-connect path never consults the connect hook regardless of address (the
> run above shows one port). It is an integrity
> bypass of the network-confinement property; no memory safety is involved.
> I score it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N (6.5 Medium) -- the
> confined task escapes the policy authority that defined its sandbox, a scope
> change; 5.5 if you treat the Landlock boundary as the same authority (S:U).
>
> Note on the in-flight UDP series
> --------------------------------
> The "landlock: Add UDP access control support" series (v5, Matthieu Buffet,
> https://lore.kernel.org/r/20260611162107.49278-3-matthieu@buffet.re) adds a
> socket_sendmsg hook, hook_socket_sendmsg(), but it returns 0 for non-UDP
> sockets:
>
> if (sk_is_udp(sock->sk))
> access_request = LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP;
> else
> return 0;
>
> so a TCP socket using MSG_FASTOPEN still bypasses LANDLOCK_ACCESS_NET_CONNECT_TCP
> even after that series lands. It may be most convenient to fix this there.
>
> Suggested direction
> -------------------
> Re-check LANDLOCK_ACCESS_NET_CONNECT_TCP on the implicit-connect path: either have
> the socket_sendmsg hook evaluate CONNECT_TCP for stream sockets when the call
> performs an implicit connect (mirroring the AF_UNIX unix_may_send handling), or
> place the check inside __inet_stream_connect() so a single chokepoint covers
> connect(2), TCP Fast Open, and the MPTCP fast-open sibling.
>
> I am happy to send a patch for this if you would like me to.
Yes please.
>
> Best regards,
>
> Bryam Vargas
> Independent security researcher, HEXLAB S.A.S., Cali, Colombia
> hexlabsecurity@proton.me
>
>
^ permalink raw reply
* Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Mickaël Salaün @ 2026-06-17 14:16 UTC (permalink / raw)
To: Jens Axboe
Cc: Bryam Vargas, Günther Noack, Paul Moore, Keith Busch,
Christoph Hellwig, Sagi Grimberg, linux-security-module,
Tingmao Wang
In-Reply-To: <209b76b4-e028-4af7-bdcb-b5813fef32fc@kernel.dk>
On Tue, Jun 16, 2026 at 08:44:55PM -0600, Jens Axboe wrote:
> On 6/16/26 8:25 PM, Bryam Vargas wrote:
> > Thanks Jens ? noted, the fix belongs in Landlock. Micka?l has the full
> > report.
>
> Indeed - and hence no need to bother anyone else with it by blasting it
> wide. I've already explained this multiple times, but on the private
> security list, when the occasional AI report comes in on things like
> this. Hence why it's a bit tiring to see the same stuff come across,
> once again.
>
> For the landlock folks, I'd suggest taking a look at what hooks already
> exists (and existed, when landlock was merged) for selinux etc, that'd
> be a really good hint on the existing surface covered.
As I explained in previous (private) reports, there is currently no
io_uring hooks implemented for Landlock because there is no use for
them.
io_uring "bypass" was already mentioned to us two times in March but
io_uring personality credential is not a Landlock bypass. The Landlock
threat model is about enforcing restrictions when accessing new kernel
resources, on a sandboxed subject. The credential identifies a set of
access rights, so in the case of io_uring, the subject is inherited by
the io_uring personality (i.e. the file descriptor). If a sandboxed
task creates an io_uring personality, it will be sandboxed with the same
restrictions, which is BTW an interesting property (e.g. pass a
restricted io_uring FD to processes)
A sandboxed process cannot create an io_uring personality that would
bypass its own restrictions, so there is no Landlock bypass. Inheriting
or receiving a file descriptor is not restricted by Landlock because
these are operations from outside (or before) the sandbox. If we want
to restrict them, we need to restrict the processes creating such file
descriptor.
Inherited or passed file descriptors are outside the Landlock threat
model because Landlock is only one part of the security policy when
(willingly) interacting with other processes. In a nutshell, it's the
security capability model (where an object has some associated rights).
For instance, if a process willingly passes a file descriptor tied to a
secret file, then the receiving side can (and should be able to) read
it, being sandboxed with Landlock or not. The scope of Landlock is to
drop ambient rights, but if an *unsandboxed* process is OK to pass a
sensitive resource, then that's a security architecture issue (i.e. a
confused deputy attack).
A nice side effect of this approach is that a process can sandbox itself
with a specific Landlock security policy and create an io_uring file
descriptor that will inherit the Landlock restrictions. It can then
pass this FD to other processes with the guarantee that this FD will
only give access to resources allowed by the Landlock policy.
Landlock could implement the security_uring_sqpoll() hook, but for now
the use case is not clear to me. We are working on controling socket
creation according to they properties and I think the same approach
would be useful for IO_URING:
https://lore.kernel.org/r/20251118134639.3314803-1-ivanov.mikhail1@huawei-partners.com
I agree that this might be confusing and I plan to improve Landlock
documentation to make this clear and simpler for AI to take into
account.
BTW, we also have an opened issue to add io_uring tests:
https://github.com/landlock-lsm/linux/issues/23
Regards,
Mickaël
^ permalink raw reply
* Re: [PATCH v5 7/8] vfs: Replace security_sb_mount/security_move_mount with granular hooks
From: Christian Brauner @ 2026-06-17 13:53 UTC (permalink / raw)
To: Song Liu
Cc: linux-security-module, linux-fsdevel, selinux, apparmor, paul,
jmorris, serge, viro, jack, john.johansen, stephen.smalley.work,
omosnace, mic, gnoack, takedakn, penguin-kernel, herton,
kernel-team
In-Reply-To: <20260528182607.3150386-8-song@kernel.org>
On Thu, May 28, 2026 at 11:26:06AM -0700, Song Liu wrote:
> Replace the monolithic security_sb_mount() call in path_mount() and
> security_move_mount() in vfs_move_mount() with the new granular mount
> hooks:
>
> - do_loopback(): call security_mount_bind()
> - do_new_mount(): call security_mount_new()
> - do_remount(): call security_mount_remount()
> - do_reconfigure_mnt(): call security_mount_reconfigure()
> - do_move_mount_old(): call security_mount_move()
> - do_change_type(): call security_mount_change_type()
> - vfs_move_mount(): replace security_move_mount() with
> security_mount_move()
>
> The new hooks are called at the individual operation level with
> appropriate context (resolved paths, fs_context), rather than at
> the top of path_mount() with raw string arguments.
>
> Code generated with the assistance of Claude, reviewed by human.
>
> Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> Tested-by: Stephen Smalley <stephen.smalley.work@gmail.com> # for selinux only
> Signed-off-by: Song Liu <song@kernel.org>
> ---
> fs/namespace.c | 41 ++++++++++++++++++++++++++++++-----------
> 1 file changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index fe919abd2f01..43f22c5e2bf4 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2888,6 +2888,10 @@ static int do_change_type(const struct path *path, int ms_flags)
> if (!type)
> return -EINVAL;
>
> + err = security_mount_change_type(path, ms_flags);
> + if (err)
> + return err;
> +
> guard(namespace_excl)();
>
> err = may_change_propagation(mnt);
> @@ -3006,6 +3010,10 @@ static int do_loopback(const struct path *path, const char *old_name,
> if (err)
> return err;
>
> + err = security_mount_bind(&old_path, path, recurse);
> + if (err)
> + return err;
This again is racy as it is called outside of the namespace semaphore:
err = security_mount_bind(&old_path, path, recurse);
if (err)
return err;
if (mnt_ns_loop(old_path.dentry))
return -EINVAL;
LOCK_MOUNT(mp, path);
if (IS_ERR(mp.parent))
return PTR_ERR(mp.parent);
After LOCK_MOUNT @path might point to a completely different mount then
the one you performed your security checks on.
> +
> if (mnt_ns_loop(old_path.dentry))
> return -EINVAL;
>
> @@ -3328,7 +3336,8 @@ static void mnt_warn_timestamp_expiry(const struct path *mountpoint,
> * superblock it refers to. This is triggered by specifying MS_REMOUNT|MS_BIND
> * to mount(2).
> */
> -static int do_reconfigure_mnt(const struct path *path, unsigned int mnt_flags)
> +static int do_reconfigure_mnt(const struct path *path, unsigned int mnt_flags,
> + unsigned long flags)
> {
> struct super_block *sb = path->mnt->mnt_sb;
> struct mount *mnt = real_mount(path->mnt);
> @@ -3343,6 +3352,10 @@ static int do_reconfigure_mnt(const struct path *path, unsigned int mnt_flags)
> if (!can_change_locked_flags(mnt, mnt_flags))
> return -EPERM;
>
> + ret = security_mount_reconfigure(path, mnt_flags, flags);
> + if (ret)
> + return ret;
> +
> /*
> * We're only checking whether the superblock is read-only not
> * changing it, so only take down_read(&sb->s_umount).
> @@ -3366,7 +3379,7 @@ static int do_reconfigure_mnt(const struct path *path, unsigned int mnt_flags)
> * on it - tough luck.
> */
> static int do_remount(const struct path *path, int sb_flags,
> - int mnt_flags, void *data)
> + int mnt_flags, void *data, unsigned long flags)
> {
> int err;
> struct super_block *sb = path->mnt->mnt_sb;
> @@ -3393,6 +3406,9 @@ static int do_remount(const struct path *path, int sb_flags,
> fc->oldapi = true;
>
> err = parse_monolithic_mount_data(fc, data);
> + if (!err)
> + err = security_mount_remount(fc, path, mnt_flags, flags,
> + data);
> if (!err) {
> down_write(&sb->s_umount);
> err = -EPERM;
> @@ -3708,6 +3724,10 @@ static int do_move_mount_old(const struct path *path, const char *old_name)
> if (err)
> return err;
>
> + err = security_mount_move(&old_path, path);
> + if (err)
> + return err;
Placement of this hook suffers from the same issue as the bind mount
hook. Here it's worse because the security layer isn't even informed
about MOVE_MOUNT_BENEATH which completely alters the mount relationship.
^ permalink raw reply
* Re: [GIT PULL] selinux/selinux-pr-20260615
From: Kuan-Wei Chiu @ 2026-06-17 13:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paul Moore, selinux, linux-security-module, linux-kernel,
Andrew Morton, jserv, marscheng
In-Reply-To: <CAHk-=wjBF1ZXNRRqnA+KDFzqxZaXPgmDc8=Ly3+RdxUXWuve9Q@mail.gmail.com>
Hi Linus,
On Wed, Jun 17, 2026 at 12:54:44PM +0100, Linus Torvalds wrote:
> On Tue, 16 Jun 2026 at 03:55, Paul Moore <paul@paul-moore.com> wrote:
> >
> > - 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
>
> So this is clearly worth fixing in the selinux code regardless, but
> did anybody check whether our sorting routines in lib/sort.c actually
> have any overflow issues with non-transitive comparison functions?
>
> Strange sort order may be confusing but tends to be largely harmless
> (the confusion might then obviously cause other issues)
>
> The whole "confuses the sort function enough to result in bad
> accesses" might be worth fixing in lib/sort.c if somebody looked into
> it...
>
Since I made most of the recent changes to lib/sort.c, I can
hopefully shed some light on this.
With the current Linux lib/sort.c implementation, passing a compare
function that lacks transitivity will absolutely **not** lead to any
out-of-bounds memory accesses. Unlike glibc which defaults to merge
sort and falls back to heapsort if malloc fails, the kernel uses a
strict in-place heapsort. Because of this, the compare and swap
operations will always operate safely within the boundaries of the
provided array.
However, it still inevitably leads to unexpected sorting results. This
has caused actual user-visible issues in the past (the previous acpi
breakage being an example [1][2]). It turns out it is easy for people
to accidentally write comparators that violate transitivity, which is
why I submitted a patch previously to emphasize the properties a
comparator must satisfy. [3]
I have actually thought about whether we could detect transitivity
violations at runtime. But if we map this to graph theory: treating
each element as a node and the comparison results as directed edges,
detecting a violation is equivalent to finding a cycle in the graph.
Doing this would require an O(n^2) time complexity, which is obviously
unacceptable at runtime.
[1]: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=233323f9b9f828cd7cd5145ad811c1990b692542
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e0a15f8b4bd47548032acccdbeb5b9083b3675e
Regards,
Kuan-Wei
^ permalink raw reply
* Re: [GIT PULL] lsm/lsm-pr-20260615
From: pr-tracker-bot @ 2026-06-17 11:59 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, linux-security-module, linux-kernel
In-Reply-To: <9b359189953cc739f62fc94af4c24a27@paul-moore.com>
The pull request you sent on Mon, 15 Jun 2026 22:55:38 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git tags/lsm-pr-20260615
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/87599bd29856ea7bfdd62591c581c8be5a4719ee
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] selinux/selinux-pr-20260615
From: pr-tracker-bot @ 2026-06-17 11:58 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, selinux, linux-security-module, linux-kernel
In-Reply-To: <577e6fb29cf0b9c335748aa5fa026275@paul-moore.com>
The pull request you sent on Mon, 15 Jun 2026 22:55:42 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20260615
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/231e9d447ea97033ae8b8dff7b910e6269d7c5af
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL] selinux/selinux-pr-20260615
From: Linus Torvalds @ 2026-06-17 11:54 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, linux-security-module, linux-kernel
In-Reply-To: <577e6fb29cf0b9c335748aa5fa026275@paul-moore.com>
On Tue, 16 Jun 2026 at 03:55, Paul Moore <paul@paul-moore.com> wrote:
>
> - 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
So this is clearly worth fixing in the selinux code regardless, but
did anybody check whether our sorting routines in lib/sort.c actually
have any overflow issues with non-transitive comparison functions?
Strange sort order may be confusing but tends to be largely harmless
(the confusion might then obviously cause other issues)
The whole "confuses the sort function enough to result in bad
accesses" might be worth fixing in lib/sort.c if somebody looked into
it...
Linus
^ permalink raw reply
* Re: [PATCH v17 05/10] rust: page: convert to `Ownable`
From: Alice Ryhl @ 2026-06-17 11:36 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Daniel Almeida, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Boqun Feng, Uladzislau Rezki,
Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Igor Korotin,
Pavel Tikhomirov, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, driver-core, Asahi Lina
In-Reply-To: <20260604-unique-ref-v17-5-7b4c3d2930b9@kernel.org>
On Thu, Jun 04, 2026 at 10:11:17PM +0200, Andreas Hindborg wrote:
> From: Asahi Lina <lina@asahilina.net>
>
> This allows Page references to be returned as borrowed references,
> without necessarily owning the struct page.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> [ Andreas: Fix formatting and add a safety comment. ]
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
> rust/kernel/page.rs | 38 +++++++++++++++++++++++++-------------
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/rust/kernel/page.rs b/rust/kernel/page.rs
> index 3bdcee0e16a8..844c75e54134 100644
> --- a/rust/kernel/page.rs
> +++ b/rust/kernel/page.rs
> @@ -10,6 +10,11 @@
> bindings,
> error::code::*,
> error::Result,
> + types::{
> + Opaque,
> + Ownable,
> + Owned, //
> + },
> uaccess::UserSliceReader, //
> };
> use core::{
> @@ -105,7 +110,7 @@ pub const fn page_align(addr: usize) -> Option<usize> {
> ///
> /// [`VBox`]: kernel::alloc::VBox
> /// [`Vmalloc`]: kernel::alloc::allocator::Vmalloc
> -pub struct BorrowedPage<'a>(ManuallyDrop<Page>, PhantomData<&'a Page>);
> +pub struct BorrowedPage<'a>(ManuallyDrop<NonNull<Page>>, PhantomData<&'a Page>);
BorrowedPage<'a> is no longer needed because it's just &Page.
Alice
^ permalink raw reply
* Re: [PATCH v3] security: Expand task_setscheduler LSM hook to include CPU affinity mask
From: Aaron Tomlin @ 2026-06-17 10:52 UTC (permalink / raw)
To: Paul Moore, peterz
Cc: peterz, 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: <CAHC9VhSROg6RGUN4_ZVBoEwYjRnKvyjnkbx2D88c09KiTgY3KQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3790 bytes --]
On Mon, Jun 15, 2026 at 06:03:06PM -0400, Paul Moore wrote:
> > 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.
Hi Paul,
Thank you for the transparent feedback.
Your point regarding the need for a comprehensive, holistic approach to
resource limits within the LSM subsystem is well taken.
To clarify my intent, my primary motivation for this patch is actually
rooted in observability and auditing, though I view the capacity for
finer-grained resource control as a natural, downstream benefit of exposing
these raw parameters to the LSM.
As I mentioned to Peter Zijlstra, because the core kernel silently
truncates the requested affinity masks before the LSM hook evaluates them,
security modules are fundamentally blind to the original userspace intent.
If a process requests an overly broad or malformed mask, an auditing tool
attached via the BPF LSM logs the sanitised outcome rather than the
attempted action. Passing the raw 'in_mask' and 'sched_attr' ensures that
security modules can accurately observe and log exactly what was requested.
That said, I completely understand your reluctance to review this while the
dependency [1][2] remain out-of-tree. I will hold off on pushing this specific
patch further until this prerequisite has officially landed in mainline.
Regarding your request for an in-tree user: when the dependency is added
and I provide the next iteration, I will ensure it includes a concrete
demonstration of this auditing capability to justify the maintenance burden
of the expanded hook signature.
Thanks again for your time and guidance.
[1]: https://lore.kernel.org/lkml/ai_T_uRkojOsTE-Z@alpha.franken.de/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=98e37db4a34d3af3fb2f4648295c25b5e40b20e3
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v17 05/10] rust: page: convert to `Ownable`
From: Alice Ryhl @ 2026-06-17 9:54 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Daniel Almeida, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Boqun Feng, Uladzislau Rezki,
Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Igor Korotin,
Pavel Tikhomirov, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, driver-core, Asahi Lina
In-Reply-To: <20260604-unique-ref-v17-5-7b4c3d2930b9@kernel.org>
On Thu, Jun 4, 2026 at 10:14 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> From: Asahi Lina <lina@asahilina.net>
>
> This allows Page references to be returned as borrowed references,
> without necessarily owning the struct page.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> [ Andreas: Fix formatting and add a safety comment. ]
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
This will not compile unless Rust Binder is also updated.
Alice
^ permalink raw reply
* Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Günther Noack @ 2026-06-17 9:47 UTC (permalink / raw)
To: Bryam Vargas
Cc: Mickaël Salaün, Paul Moore, Jens Axboe, Keith Busch,
Christoph Hellwig, Sagi Grimberg, linux-security-module, io-uring,
linux-block, linux-nvme, linux-kernel
In-Reply-To: <20260616201633.275067-1-hexlabsecurity@proton.me>
Hello Bryam!
Thanks for the report!
On Tue, Jun 16, 2026 at 08:16:41PM +0000, Bryam Vargas wrote:
> Hello Mickaël, and Landlock / io_uring folks,
>
> A task confined by a Landlock ruleset that grants READ_FILE/WRITE_FILE on a block
> or NVMe character device but withholds LANDLOCK_ACCESS_FS_IOCTL_DEV can still
> reach the device-command surface through io_uring IORING_OP_URING_CMD with the
> IOCTL_DEV check bypassed: the request enters the device-command handler (block
> discard, or the NVMe char-device passthrough) where the equivalent ioctl(2) is
> denied. The destructive completion and the NVMe-admin surface follow from the
> code -- see Impact.
>
> Affected
> --------
> Any kernel with CONFIG_SECURITY_LANDLOCK=y and Landlock enabled that supports
> LANDLOCK_ACCESS_FS_IOCTL_DEV (Landlock ABI >= 5, since Linux 6.8) and io_uring
> uring_cmd for the device class (block BLOCK_URING_CMD_DISCARD; NVMe passthrough).
> Confirmed by source inspection on mainline (v7.1-rc7) and reproduced on Linux
> 7.0.11 (Landlock ABI 8). The confined task needs a writable fd to a device it is
> legitimately allowed to use (e.g. a partition/loop device or an NVMe namespace
> passed into a container or granted by the ruleset); no CAP is required to reach
> the io_uring path. The gap is structural -- Landlock has never registered a
> uring_cmd hook -- so it is present from ABI 5 (Linux 6.8) through current
> mainline (v7.1-rc7) and is not a regression tied to a single Fixes: commit.
>
> Root cause
> ----------
> On the ioctl(2) path, the syscall handler in fs/ioctl.c calls
> security_file_ioctl() (its only call site on the ioctl(2) path) before
> dispatching to do_vfs_ioctl(); that reaches Landlock hook_file_ioctl_common(),
> which denies a device ioctl unless the file's
> allowed_access holds LANDLOCK_ACCESS_FS_IOCTL_DEV (BLKDISCARD/BLKSECDISCARD/
> BLKZEROOUT and NVMe passthrough are not in the is_masked_device_ioctl()
> allow-list, so they require the right).
>
> io_uring reaches the same device-command surface by a different producer:
>
> IORING_OP_URING_CMD -> io_uring_cmd() io_uring/uring_cmd.c
> -> security_uring_cmd(ioucmd) (the ONLY LSM gate on this path)
> -> file->f_op->uring_cmd() e.g. blkdev_uring_cmd() / nvme_ns_chr_uring_cmd()
>
> Landlock's LSM_HOOK_INIT list (security/landlock/fs.c, net.c, task.c) registers
> file_ioctl/file_ioctl_compat but no uring_cmd hook -- only SELinux
> (selinux_uring_cmd) and Smack (smack_uring_cmd) gate this surface -- so
> security_uring_cmd() returns 0 for a Landlocked task and hook_file_ioctl /
> IOCTL_DEV is never consulted. For block, blkdev_cmd_discard() is then gated only
> by BLK_OPEN_WRITE; for NVMe, nvme_ns_chr_uring_cmd() reaches the admin/IO
> passthrough with no security_file_ioctl on the path. There is no shared helper
> that re-applies the IOCTL_DEV check.
>
> SELinux and Smack hooking uring_cmd while Landlock does not is the coverage
> asymmetry; the Landlock documentation describes IOCTL_DEV as gating ioctl(2) but
> does not mention io_uring.
>
> Reproducer
> ----------
> A self-contained PoC is available on request (it needs root only to set up a loop
> block device and open it; Landlock enforcement is uid-independent, so the
> confined child demonstrates the gap regardless of the setup uid). The child
> applies a Landlock ruleset handling READ_FILE|WRITE_FILE|IOCTL_DEV with a rule
> granting only READ_FILE|WRITE_FILE on the device, then:
>
> (1) ioctl(fd, BLKDISCARD, range) -> -EACCES (Landlock enforces IOCTL_DEV)
> (2) IORING_OP_URING_CMD,
> cmd_op = BLOCK_URING_CMD_DISCARD -> reaches the block command handler
>
> Observed on Linux 7.0.11 (Landlock ABI 8):
>
> [1] ioctl(BLKDISCARD) -> ret=-1 errno=13 (Permission denied)
> [2] uring_cmd(DISCARD) -> cqe.res=-22 (Invalid argument)
>
> A Landlock denial is always -EACCES; the io_uring path returned -EINVAL, which
> originates in a post-authorization check inside the block command handler
> (blk_validate_byte_range() in blkdev_cmd_discard()), reached only after
> security_uring_cmd() returned 0. So this run demonstrates the authorization
> bypass -- the request traversed the LSM gate into the block device-command
> handler with no IOCTL_DEV check -- and then failed a parameter check, not an
> authorization check. The destructive completion (an authorized discard with a
> granularity-aligned range) is the expected behaviour but was not exercised in
> this run.
>
> Impact
> ------
> Demonstrated: the LANDLOCK_ACCESS_FS_IOCTL_DEV authorization is bypassed. The
> device-command request reaches the block command handler with no Landlock check;
> the only remaining gate is BLK_OPEN_WRITE (held, since the policy granted write).
> Inferred from the code, not exercised here: an authorized DISCARD with a valid
> range completes (DISCARD/secure-erase semantics, destroying on-device data), and
> the same missing hook leaves the NVMe char-device uring_cmd surface ungated --
> nvme_ns_chr_uring_cmd (namespace device /dev/nvmeXnY) -> nvme_ns_uring_cmd for
> NVME_URING_CMD_IO/IO_VEC passthrough, and nvme_dev_uring_cmd (controller device
> /dev/nvmeX) for NVME_URING_CMD_ADMIN (format, sanitize, firmware download,
> security send) -- both reach f_op->uring_cmd with no Landlock/IOCTL_DEV gate.
>
> So the confirmed finding is a missing authorization (the confined task escapes
> its own IOCTL_DEV restriction); the destructive data effect and the NVMe-admin
> high-water-mark follow from the code but are not shown in the run above. The
> proven authorization bypass alone scores CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N
> (6.5 Medium) -- S:C because the confined task crosses the Landlock policy
> boundary it was placed under, I:H because the bypassed path reaches a handler
> whose authorized completion modifies device data. With the device command
> completing destructively the projected ceiling is
> CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H (8.4 High), the A:H component
> reasoned from the source rather than executed. No memory safety is involved.
>
> Suggested direction
> -------------------
> Have Landlock register a uring_cmd hook that maps the device command to the same
> checks the ioctl path applies (IOCTL_DEV, and truncate where relevant), so a
> single chokepoint covers every f_op->uring_cmd provider (block, NVMe, ublk, and
> any future one). Mirrors how SELinux/Smack already gate this surface.
>
> I am happy to send a patch for this if you would like.
I have read through the code a bit, but I am not sure I follow the argument of
this report. Let me paraphrase my understanding --
* LANDLOCK_ACCESS_FS_IOCTL_DEV is documented as blocking ioctl(2)
commands on opened character and block devices.
(c.f. https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags)
* One of many block-device IOCTL operations is BLKDISCARD.
* Block devices offer BLKDISCARD over io_uring as well,
but io_uring does *not* offer a generic interface through which you
can do IOCTLs. It *only* implements BLOCK_URING_CMD_DISCARD in that
place. The header where that constant is defined happens to use one
of the ioctl macros to construct the number, but points out that "It's
a different number space from ioctl()" (see
include/uapi/linux/blkdev.h).
So... while this is similar to IOCTL, and while this block device operation is
also available through ioctl(2), this is a different command multiplexer
than IOCTL and I am not convinced that that namespace should be guarded with
the same LANDLOCK_ACCESS_FS_IOCTL_DEV access right.
Do I understand correctly that the only operation affected in this report is
BLOCK_URING_CMD_DISCARD? Or are there other operations affected by this
(through other devices)? I saw you also mentioned the truncate right above,
but I assume that for this access right you have not found a way to side-step
it (assuming that this calls the more specific LSM hooks).
Thanks,
—Günther
^ permalink raw reply
* [syzbot] [tomoyo?] KMSAN: uninit-value in tomoyo_path_chown (3)
From: syzbot @ 2026-06-17 8:41 UTC (permalink / raw)
To: jmorris, linux-kernel, linux-security-module, paul,
penguin-kernel, serge, syzkaller-bugs, takedakn, tomoyo-users_en
Hello,
syzbot found the following issue on:
HEAD commit: 2b414a95b8f7 Merge tag 's390-7.1-5' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12cff156580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a0ca3b8cb3875012
dashboard link: https://syzkaller.appspot.com/bug?extid=eaae8fa60ce81f1e4eeb
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d7dcdf890eed/disk-2b414a95.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/214784598f3b/vmlinux-2b414a95.xz
kernel image: https://storage.googleapis.com/syzbot-assets/403c25c5a3db/bzImage-2b414a95.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+eaae8fa60ce81f1e4eeb@syzkaller.appspotmail.com
=====================================================
BUG: KMSAN: uninit-value in tomoyo_path_chown+0x128/0x270 security/tomoyo/tomoyo.c:380
tomoyo_path_chown+0x128/0x270 security/tomoyo/tomoyo.c:380
security_path_chown+0x1c0/0x710 security/security.c:1598
chown_common+0x69f/0xcb0 fs/open.c:771
do_fchownat+0x20f/0x490 fs/open.c:804
__do_sys_chown fs/open.c:824 [inline]
__se_sys_chown fs/open.c:822 [inline]
__x64_sys_chown+0x9d/0x110 fs/open.c:822
x64_sys_call+0x30cc/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:93
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15d/0x3c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable newattrs created at:
chown_common+0xbc/0xcb0 fs/open.c:746
do_fchownat+0x20f/0x490 fs/open.c:804
CPU: 1 UID: 0 PID: 4943 Comm: udevd Not tainted syzkaller #0 PREEMPT(lazy)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026
=====================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Jens Axboe @ 2026-06-17 2:44 UTC (permalink / raw)
To: Bryam Vargas
Cc: Mickaël Salaün, Günther Noack,
linux-security-module
In-Reply-To: <20260617022541.328550-1-hexlabsecurity@proton.me>
On 6/16/26 8:25 PM, Bryam Vargas wrote:
> Thanks Jens ? noted, the fix belongs in Landlock. Micka?l has the full
> report.
Indeed - and hence no need to bother anyone else with it by blasting it
wide. I've already explained this multiple times, but on the private
security list, when the occasional AI report comes in on things like
this. Hence why it's a bit tiring to see the same stuff come across,
once again.
For the landlock folks, I'd suggest taking a look at what hooks already
exists (and existed, when landlock was merged) for selinux etc, that'd
be a really good hint on the existing surface covered.
--
Jens Axboe
^ permalink raw reply
* Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Bryam Vargas @ 2026-06-17 2:25 UTC (permalink / raw)
To: Jens Axboe
Cc: Mickaël Salaün, Günther Noack,
linux-security-module
In-Reply-To: <fcfa9bc9-4f7d-478c-90a2-ec4efd4c7d43@kernel.dk>
Thanks Jens — noted, the fix belongs in Landlock. Mickaël has the full report.
Bryam
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-17 2:20 UTC (permalink / raw)
To: Roman Gushchin
Cc: Mickaël Salaün, linux-security-module, sashiko,
Günther Noack
In-Reply-To: <7ia4v7biqe64.fsf@castle.c.googlers.com>
On Tue, Jun 16, 2026 at 7:06 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> Mickaël Salaün <mic@digikod.net> writes:
> > On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> >> On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> >> > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> >> > > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
...
> >> I would suggest enabling Sashiko for the LSM list, but not enabling
> >> the email replies at first. This would allow people to view the
> >> reviews and perhaps make a better informed decision.
>
> I just did this: 611f4cd410d9a7f7ad923a068a6ced455e3a244e , for enabling
> reviews I don't really need maintainers consensus. (I might roll it out
> a bit later)
>
> But when it comes to email policy I do, so I'll just sit and wait here.
Thanks Roman.
--
paul-moore.com
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Roman Gushchin @ 2026-06-16 23:05 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Paul Moore, linux-security-module, sashiko, Günther Noack
In-Reply-To: <20260616.aiGaim8xie8z@digikod.net>
Mickaël Salaün <mic@digikod.net> writes:
> On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
>> On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
>> > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
>> > > 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.
>> >
>> > As I explained just above, the PR is a draft (GitHub specific state for
>> > WIP), so it cannot be merged as-is, but it is useful for reviews and for
>> > LSM folks to get a look if they are interested.
>> >
>> > > Personally, I'm okay with it.
>> >
>> > Looks good. What about waiting a week to get some feedback here and
>> > then ask for a merge of the PR?
>>
>> I would suggest enabling Sashiko for the LSM list, but not enabling
>> the email replies at first. This would allow people to view the
>> reviews and perhaps make a better informed decision.
I just did this: 611f4cd410d9a7f7ad923a068a6ced455e3a244e , for enabling
reviews I don't really need maintainers consensus. (I might roll it out
a bit later)
But when it comes to email policy I do, so I'll just sit and wait here.
Thanks
^ permalink raw reply
* Re: Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Jens Axboe @ 2026-06-16 20:36 UTC (permalink / raw)
To: Bryam Vargas, Mickaël Salaün
Cc: Günther Noack, Paul Moore, Keith Busch, Christoph Hellwig,
Sagi Grimberg, linux-security-module, io-uring, linux-block,
linux-nvme, linux-kernel
In-Reply-To: <20260616201633.275067-1-hexlabsecurity@proton.me>
On 6/16/26 2:16 PM, Bryam Vargas wrote:
> Hello Micka?l, and Landlock / io_uring folks,
>
> A task confined by a Landlock ruleset that grants READ_FILE/WRITE_FILE
> on a block or NVMe character device but withholds
> LANDLOCK_ACCESS_FS_IOCTL_DEV can still reach the device-command
> surface through io_uring IORING_OP_URING_CMD with the IOCTL_DEV check
> bypassed: the request enters the device-command handler (block
> discard, or the NVMe char-device passthrough) where the equivalent
> ioctl(2) is denied. The destructive completion and the NVMe-admin
> surface follow from the code -- see Impact.
I've said this before, but apparently it hasn't been received - this
isn't an io_uring issue. If landlock is missing a hook, then that's on
landlock and they should add it. Other security handlers already have
that. Hence no need to broadcast this to a bunch of lists, it's strictly
a landlock issue.
--
Jens Axboe
^ permalink raw reply
* Landlock: LANDLOCK_ACCESS_FS_IOCTL_DEV bypass via io_uring IORING_OP_URING_CMD
From: Bryam Vargas @ 2026-06-16 20:16 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Paul Moore, Jens Axboe, Keith Busch,
Christoph Hellwig, Sagi Grimberg, linux-security-module, io-uring,
linux-block, linux-nvme, linux-kernel
Hello Mickaël, and Landlock / io_uring folks,
A task confined by a Landlock ruleset that grants READ_FILE/WRITE_FILE on a block
or NVMe character device but withholds LANDLOCK_ACCESS_FS_IOCTL_DEV can still
reach the device-command surface through io_uring IORING_OP_URING_CMD with the
IOCTL_DEV check bypassed: the request enters the device-command handler (block
discard, or the NVMe char-device passthrough) where the equivalent ioctl(2) is
denied. The destructive completion and the NVMe-admin surface follow from the
code -- see Impact.
Affected
--------
Any kernel with CONFIG_SECURITY_LANDLOCK=y and Landlock enabled that supports
LANDLOCK_ACCESS_FS_IOCTL_DEV (Landlock ABI >= 5, since Linux 6.8) and io_uring
uring_cmd for the device class (block BLOCK_URING_CMD_DISCARD; NVMe passthrough).
Confirmed by source inspection on mainline (v7.1-rc7) and reproduced on Linux
7.0.11 (Landlock ABI 8). The confined task needs a writable fd to a device it is
legitimately allowed to use (e.g. a partition/loop device or an NVMe namespace
passed into a container or granted by the ruleset); no CAP is required to reach
the io_uring path. The gap is structural -- Landlock has never registered a
uring_cmd hook -- so it is present from ABI 5 (Linux 6.8) through current
mainline (v7.1-rc7) and is not a regression tied to a single Fixes: commit.
Root cause
----------
On the ioctl(2) path, the syscall handler in fs/ioctl.c calls
security_file_ioctl() (its only call site on the ioctl(2) path) before
dispatching to do_vfs_ioctl(); that reaches Landlock hook_file_ioctl_common(),
which denies a device ioctl unless the file's
allowed_access holds LANDLOCK_ACCESS_FS_IOCTL_DEV (BLKDISCARD/BLKSECDISCARD/
BLKZEROOUT and NVMe passthrough are not in the is_masked_device_ioctl()
allow-list, so they require the right).
io_uring reaches the same device-command surface by a different producer:
IORING_OP_URING_CMD -> io_uring_cmd() io_uring/uring_cmd.c
-> security_uring_cmd(ioucmd) (the ONLY LSM gate on this path)
-> file->f_op->uring_cmd() e.g. blkdev_uring_cmd() / nvme_ns_chr_uring_cmd()
Landlock's LSM_HOOK_INIT list (security/landlock/fs.c, net.c, task.c) registers
file_ioctl/file_ioctl_compat but no uring_cmd hook -- only SELinux
(selinux_uring_cmd) and Smack (smack_uring_cmd) gate this surface -- so
security_uring_cmd() returns 0 for a Landlocked task and hook_file_ioctl /
IOCTL_DEV is never consulted. For block, blkdev_cmd_discard() is then gated only
by BLK_OPEN_WRITE; for NVMe, nvme_ns_chr_uring_cmd() reaches the admin/IO
passthrough with no security_file_ioctl on the path. There is no shared helper
that re-applies the IOCTL_DEV check.
SELinux and Smack hooking uring_cmd while Landlock does not is the coverage
asymmetry; the Landlock documentation describes IOCTL_DEV as gating ioctl(2) but
does not mention io_uring.
Reproducer
----------
A self-contained PoC is available on request (it needs root only to set up a loop
block device and open it; Landlock enforcement is uid-independent, so the
confined child demonstrates the gap regardless of the setup uid). The child
applies a Landlock ruleset handling READ_FILE|WRITE_FILE|IOCTL_DEV with a rule
granting only READ_FILE|WRITE_FILE on the device, then:
(1) ioctl(fd, BLKDISCARD, range) -> -EACCES (Landlock enforces IOCTL_DEV)
(2) IORING_OP_URING_CMD,
cmd_op = BLOCK_URING_CMD_DISCARD -> reaches the block command handler
Observed on Linux 7.0.11 (Landlock ABI 8):
[1] ioctl(BLKDISCARD) -> ret=-1 errno=13 (Permission denied)
[2] uring_cmd(DISCARD) -> cqe.res=-22 (Invalid argument)
A Landlock denial is always -EACCES; the io_uring path returned -EINVAL, which
originates in a post-authorization check inside the block command handler
(blk_validate_byte_range() in blkdev_cmd_discard()), reached only after
security_uring_cmd() returned 0. So this run demonstrates the authorization
bypass -- the request traversed the LSM gate into the block device-command
handler with no IOCTL_DEV check -- and then failed a parameter check, not an
authorization check. The destructive completion (an authorized discard with a
granularity-aligned range) is the expected behaviour but was not exercised in
this run.
Impact
------
Demonstrated: the LANDLOCK_ACCESS_FS_IOCTL_DEV authorization is bypassed. The
device-command request reaches the block command handler with no Landlock check;
the only remaining gate is BLK_OPEN_WRITE (held, since the policy granted write).
Inferred from the code, not exercised here: an authorized DISCARD with a valid
range completes (DISCARD/secure-erase semantics, destroying on-device data), and
the same missing hook leaves the NVMe char-device uring_cmd surface ungated --
nvme_ns_chr_uring_cmd (namespace device /dev/nvmeXnY) -> nvme_ns_uring_cmd for
NVME_URING_CMD_IO/IO_VEC passthrough, and nvme_dev_uring_cmd (controller device
/dev/nvmeX) for NVME_URING_CMD_ADMIN (format, sanitize, firmware download,
security send) -- both reach f_op->uring_cmd with no Landlock/IOCTL_DEV gate.
So the confirmed finding is a missing authorization (the confined task escapes
its own IOCTL_DEV restriction); the destructive data effect and the NVMe-admin
high-water-mark follow from the code but are not shown in the run above. The
proven authorization bypass alone scores CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N
(6.5 Medium) -- S:C because the confined task crosses the Landlock policy
boundary it was placed under, I:H because the bypassed path reaches a handler
whose authorized completion modifies device data. With the device command
completing destructively the projected ceiling is
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H (8.4 High), the A:H component
reasoned from the source rather than executed. No memory safety is involved.
Suggested direction
-------------------
Have Landlock register a uring_cmd hook that maps the device command to the same
checks the ioctl path applies (IOCTL_DEV, and truncate where relevant), so a
single chokepoint covers every f_op->uring_cmd provider (block, NVMe, ublk, and
any future one). Mirrors how SELinux/Smack already gate this surface.
I am happy to send a patch for this if you would like.
Best regards,
Bryam Vargas
Independent security researcher, HEXLAB S.A.S., Cali, Colombia
hexlabsecurity@proton.me
^ permalink raw reply
* Landlock: LANDLOCK_ACCESS_NET_CONNECT_TCP bypass via TCP Fast Open
From: Bryam Vargas @ 2026-06-16 20:16 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Matthieu Buffet, Paul Moore, Eric Dumazet,
Neal Cardwell, linux-security-module, netdev, linux-kernel
Hello Mickaël, and Landlock folks,
A task confined by a Landlock ruleset that handles
LANDLOCK_ACCESS_NET_CONNECT_TCP and is denied connecting to a given port can
still establish a TCP connection to that port by using TCP Fast Open, i.e.
sendto(fd, ..., MSG_FASTOPEN, &dst, dstlen) on a fresh stream socket. The
network-egress confinement for TCP connect is silently bypassed.
Affected
--------
Any kernel with CONFIG_SECURITY_LANDLOCK=y and Landlock enabled that supports
the TCP network access rights (Landlock ABI >= 4, since Linux 6.7). Confirmed by
source inspection on mainline (v7.1-rc7) and reproduced on Linux 7.0.11
(Landlock ABI 8). No CONFIG beyond Landlock + IPv4/IPv6 TCP; TCP Fast Open client
is enabled by the per-netns default (net.ipv4.tcp_fastopen has TFO_CLIENT_ENABLE
set), so no sysctl change and no setsockopt are required.
Root cause
----------
LANDLOCK_ACCESS_NET_CONNECT_TCP is enforced only by the socket_connect LSM hook
(hook_socket_connect -> current_check_access_socket). security_socket_connect()
has exactly one call site in the tree, net/socket.c (the connect(2) syscall).
TCP Fast Open performs an implicit connect inside sendmsg:
tcp_sendmsg_locked() net/ipv4/tcp.c (MSG_FASTOPEN branch)
-> tcp_sendmsg_fastopen() net/ipv4/tcp.c
-> __inet_stream_connect(..., is_sendmsg=1) net/ipv4/af_inet.c
-> sk->sk_prot->connect() net/ipv4/af_inet.c -> tcp_v4_connect()
This path establishes the connection to the address taken from msg_name but
never calls security_socket_connect(). The only LSM hook fired on the sendmsg
path is security_socket_sendmsg(), and Landlock registers no socket_sendmsg
hook, so LANDLOCK_ACCESS_NET_CONNECT_TCP is never re-checked. __inet_stream_connect()
itself carries no LSM hook (only the cgroup-BPF pre_connect, a different
mechanism).
Notably the kernel already mediates the analogous AF_UNIX implicit-connect on the
send path via the unix_may_send hook, which Landlock does register
(hook_unix_may_send) -- so the sendmsg-implies-connect pattern is recognized, but
the TCP Fast Open case has no equivalent coverage. The MPTCP fast-open path
(mptcp_sendmsg_fastopen -> __inet_stream_connect) is a second producer of the
same unmediated connect (by source inspection; not separately reproduced).
Reproducer
----------
A self-contained, fully unprivileged PoC is available on request. It forks an
unconfined TFO-capable loopback listener, then in a child applies a Landlock
ruleset handling LANDLOCK_ACCESS_NET_CONNECT_TCP with no allow rule
(landlock_create_ruleset() with handled_access_net =
LANDLOCK_ACCESS_NET_CONNECT_TCP, no landlock_add_rule(), then
landlock_restrict_self(); every TCP connect is denied) and tries the forbidden
port two ways:
(1) connect(fd, &dst) -> -EACCES (Landlock enforces CONNECT_TCP)
(2) sendto(fd2, buf, len, MSG_FASTOPEN, &dst, dstlen)
-> succeeds; the listener accepts the
connection and reads the payload.
Observed on Linux 7.0.11 (Landlock ABI 8):
[1] connect(2) -> ret=-1 errno=13 (Permission denied)
[2] sendto(MSG_FASTOPEN) -> ret=14 errno=0 (OK/queued)
[+] listener ACCEPTED the confined child's connection; payload="..."
connect(2) to the port is denied while sendto(MSG_FASTOPEN) reaches the identical
port and delivers data.
Impact
------
A sandbox that uses LANDLOCK_ACCESS_NET_CONNECT_TCP to restrict outbound TCP
(e.g. to keep a confined component from reaching an internal service or a
metadata endpoint) can be escaped by an unprivileged, self-confined task with no
CAP and no namespace transition -- for any destination port, since the
implicit-connect path never consults the connect hook regardless of address (the
run above shows one port). It is an integrity
bypass of the network-confinement property; no memory safety is involved.
I score it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N (6.5 Medium) -- the
confined task escapes the policy authority that defined its sandbox, a scope
change; 5.5 if you treat the Landlock boundary as the same authority (S:U).
Note on the in-flight UDP series
--------------------------------
The "landlock: Add UDP access control support" series (v5, Matthieu Buffet,
https://lore.kernel.org/r/20260611162107.49278-3-matthieu@buffet.re) adds a
socket_sendmsg hook, hook_socket_sendmsg(), but it returns 0 for non-UDP
sockets:
if (sk_is_udp(sock->sk))
access_request = LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP;
else
return 0;
so a TCP socket using MSG_FASTOPEN still bypasses LANDLOCK_ACCESS_NET_CONNECT_TCP
even after that series lands. It may be most convenient to fix this there.
Suggested direction
-------------------
Re-check LANDLOCK_ACCESS_NET_CONNECT_TCP on the implicit-connect path: either have
the socket_sendmsg hook evaluate CONNECT_TCP for stream sockets when the call
performs an implicit connect (mirroring the AF_UNIX unix_may_send handling), or
place the check inside __inet_stream_connect() so a single chokepoint covers
connect(2), TCP Fast Open, and the MPTCP fast-open sibling.
I am happy to send a patch for this if you would like me to.
Best regards,
Bryam Vargas
Independent security researcher, HEXLAB S.A.S., Cali, Colombia
hexlabsecurity@proton.me
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-16 19:03 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <CAHC9VhQyN3CczsTHG=sJF8G=MqxGL6NO7assuAjuF9K1t-qDmQ@mail.gmail.com>
On Tue, Jun 16, 2026 at 11:23:54AM -0400, Paul Moore wrote:
> On Tue, Jun 16, 2026 at 10:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> > On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> > > On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > > > > 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.
> > > >
> > > > As I explained just above, the PR is a draft (GitHub specific state for
> > > > WIP), so it cannot be merged as-is, but it is useful for reviews and for
> > > > LSM folks to get a look if they are interested.
> > > >
> > > > > Personally, I'm okay with it.
> > > >
> > > > Looks good. What about waiting a week to get some feedback here and
> > > > then ask for a merge of the PR?
> > >
> > > I would suggest enabling Sashiko for the LSM list, but not enabling
> > > the email replies at first. This would allow people to view the
> > > reviews and perhaps make a better informed decision.
> >
> > The point of this PR and the related discussion is to enable email
> > replies ...
>
> ... and you've heard my opinions on that.
>
> > the reviews are already there.
>
> I don't believe the LSM list is being directly reviewed by sashiko.dev
> at the moment (check the lists drop-down in the web UI). Any
> LSM-posted patches being reviewed are being reviewed due to a CC to a
> sashiko.dev monitored list.
I reiterate my claim that the LSM list is already being reviewed. You
just need to enter an LSM name in the search box to see the reviewed
patch series. They are already categorized by mailing list, only the
drop-down menu doesn't list all of them. For instance, the latest for
AppArmor (neither the LKML nor the LSM mailing list are being explicitly
registered for Sashiko):
https://sashiko.dev/#/patchset/20260613060424.2213712-1-junxiao.chang%40intel.com
>
> > As explained, my motivation for
> > this change is to get reviews, and without emails I suspect almost nobody
> > (will) take a look and that would not even be an experiment. I'm saying
> > that because I forgot several times to take a look and it adds more work
> > to the review/maintenance.
>
> I think it's important to allow people a chance to see what the
> reviews are like before you enable an automated bot on the mailing
> list. I'm sorry you found it cumbersome to check the web UI, but a
> change to what is sent to the mailing list affects more than just you.
>
> Perhaps we do eventually enable sashiko.dev to post to the LSM list,
> as I said before I have no problem with that, but I want to give
> people a chance to look at the Sashiko reviews first and make a more
> informed decision.
Sure, I sent this emails to start this discussion, and we can already
take a look, but I guess a drop-down menu will help. Are you OK to
start with this drop-down menu?
>
> > FWIW, there are currently 41 kernel mailing lists registered:
> > https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml
>
> Yes, I think we can all read a configuration file.
>
> > > > Anyway, it would not be written in
> > > > stone, we can update Sashiko config with new PRs.
> > >
> > > It is worth noting that sashiko.dev updates are not immediate, so
> > > there is a delay between a PR being merged and it taking effect.
> >
> > Sure and I don't think it's an issue. It's really easy to filter
> > emails on any MUA if really needed, and I'm sure the Sashiko maintainers
> > would be able to fix things quickly if needed.
>
> I think it's important to understand that not everyone approaches the
> email lists the same way, and something that is a non-issue for you
> might be a larger issue for someone else.
I know, it's not about me.
>
> As a reminder, you are always welcome to create your own list for
> Landlock if you find that the LSM list no longer meets your needs.
> The only thing I ask is that any patches touching/affecting the LSM
> framework are sent to the LSM list and of course any pull requests
> sent to Linus should CC the LSM list.
That would be easier, but that's an option I would prefer to avoid
because I want everyone to benefit form these reviews.
^ permalink raw reply
* Re: [PATCH] security: clarify task_prctl hook documentation
From: Serge E. Hallyn @ 2026-06-16 17:14 UTC (permalink / raw)
To: Casey Schaufler
Cc: Bill Roberts, Paul Moore, James Morris, Serge E. Hallyn,
linux-security-module, linux-kernel
In-Reply-To: <bdf7591c-4078-4ee5-9e63-e5dc27602fb6@schaufler-ca.com>
On Tue, Jun 16, 2026 at 09:07:40AM -0700, Casey Schaufler wrote:
> On 6/15/2026 1:03 PM, Bill Roberts wrote:
> > 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>
>
> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Yeah, this is an important distinction, thanks.
Reviewed-by: Serge Hallyn <serge@hallyn.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.
^ permalink raw reply
* Re: [PATCH] security: clarify task_prctl hook documentation
From: Casey Schaufler @ 2026-06-16 16:07 UTC (permalink / raw)
To: Bill Roberts, Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-security-module, linux-kernel, Casey Schaufler
In-Reply-To: <20260615200325.260057-1-bill.roberts@arm.com>
On 6/15/2026 1:03 PM, Bill Roberts wrote:
> 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>
Acked-by: Casey Schaufler <casey@schaufler-ca.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.
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-16 15:23 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <20260616.aiGaim8xie8z@digikod.net>
On Tue, Jun 16, 2026 at 10:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> > On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > > > 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.
> > >
> > > As I explained just above, the PR is a draft (GitHub specific state for
> > > WIP), so it cannot be merged as-is, but it is useful for reviews and for
> > > LSM folks to get a look if they are interested.
> > >
> > > > Personally, I'm okay with it.
> > >
> > > Looks good. What about waiting a week to get some feedback here and
> > > then ask for a merge of the PR?
> >
> > I would suggest enabling Sashiko for the LSM list, but not enabling
> > the email replies at first. This would allow people to view the
> > reviews and perhaps make a better informed decision.
>
> The point of this PR and the related discussion is to enable email
> replies ...
... and you've heard my opinions on that.
> the reviews are already there.
I don't believe the LSM list is being directly reviewed by sashiko.dev
at the moment (check the lists drop-down in the web UI). Any
LSM-posted patches being reviewed are being reviewed due to a CC to a
sashiko.dev monitored list.
> As explained, my motivation for
> this change is to get reviews, and without emails I suspect almost nobody
> (will) take a look and that would not even be an experiment. I'm saying
> that because I forgot several times to take a look and it adds more work
> to the review/maintenance.
I think it's important to allow people a chance to see what the
reviews are like before you enable an automated bot on the mailing
list. I'm sorry you found it cumbersome to check the web UI, but a
change to what is sent to the mailing list affects more than just you.
Perhaps we do eventually enable sashiko.dev to post to the LSM list,
as I said before I have no problem with that, but I want to give
people a chance to look at the Sashiko reviews first and make a more
informed decision.
> FWIW, there are currently 41 kernel mailing lists registered:
> https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml
Yes, I think we can all read a configuration file.
> > > Anyway, it would not be written in
> > > stone, we can update Sashiko config with new PRs.
> >
> > It is worth noting that sashiko.dev updates are not immediate, so
> > there is a delay between a PR being merged and it taking effect.
>
> Sure and I don't think it's an issue. It's really easy to filter
> emails on any MUA if really needed, and I'm sure the Sashiko maintainers
> would be able to fix things quickly if needed.
I think it's important to understand that not everyone approaches the
email lists the same way, and something that is a non-issue for you
might be a larger issue for someone else.
As a reminder, you are always welcome to create your own list for
Landlock if you find that the LSM list no longer meets your needs.
The only thing I ask is that any patches touching/affecting the LSM
framework are sent to the LSM list and of course any pull requests
sent to Linus should CC the LSM list.
--
paul-moore.com
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-16 14:59 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <CAHC9VhRa8DQ-ekrmPQSg2pO9pBFj6GA9DO=x5kguGFTbKKyv7Q@mail.gmail.com>
On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > > 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.
> >
> > As I explained just above, the PR is a draft (GitHub specific state for
> > WIP), so it cannot be merged as-is, but it is useful for reviews and for
> > LSM folks to get a look if they are interested.
> >
> > > Personally, I'm okay with it.
> >
> > Looks good. What about waiting a week to get some feedback here and
> > then ask for a merge of the PR?
>
> I would suggest enabling Sashiko for the LSM list, but not enabling
> the email replies at first. This would allow people to view the
> reviews and perhaps make a better informed decision.
The point of this PR and the related discussion is to enable email
replies, the reviews are already there. As explained, my motivation for
this change is to get reviews, and without emails I suspect almost nobody
(will) take a look and that would not even be an experiment. I'm saying
that because I forgot several times to take a look and it adds more work
to the review/maintenance.
FWIW, there are currently 41 kernel mailing lists registered:
https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml
>
> > Anyway, it would not be written in
> > stone, we can update Sashiko config with new PRs.
>
> It is worth noting that sashiko.dev updates are not immediate, so
> there is a delay between a PR being merged and it taking effect.
Sure and I don't think it's an issue. It's really easy to filter
emails on any MUA if really needed, and I'm sure the Sashiko maintainers
would be able to fix things quickly if needed.
^ 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