* 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
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-16 14:11 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <20260616.EPh8ked0niko@digikod.net>
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.
> 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.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v17 03/10] rust: implement `ForeignOwnable` for `Owned`
From: Gary Guo @ 2026-06-16 11:55 UTC (permalink / raw)
To: Andreas Hindborg, Miguel Ojeda, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, 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
Cc: linux-kernel, rust-for-linux, linux-block, linux-security-module,
dri-devel, linux-fsdevel, linux-mm, linux-pm, linux-pci,
driver-core
In-Reply-To: <20260604-unique-ref-v17-3-7b4c3d2930b9@kernel.org>
On Thu Jun 4, 2026 at 9:11 PM BST, Andreas Hindborg wrote:
> Implement `ForeignOwnable` for `Owned<T>`. This allows use of `Owned<T>` in
> places such as the `XArray`.
>
> Note that `T` does not need to implement `ForeignOwnable` for `Owned<T>` to
> implement `ForeignOwnable`.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
> rust/kernel/owned.rs | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/rust/kernel/owned.rs b/rust/kernel/owned.rs
> index 456e239e906e..5eacdf327d12 100644
> --- a/rust/kernel/owned.rs
> +++ b/rust/kernel/owned.rs
> @@ -15,6 +15,8 @@
> ptr::NonNull, //
> };
>
> +use kernel::types::ForeignOwnable;
> +
> /// Types that specify their own way of performing allocation and destruction. Typically, this trait
> /// is implemented on types from the C side.
> ///
> @@ -108,6 +110,7 @@ pub trait Ownable {
> ///
> /// - Until `T::release` is called, this `Owned<T>` exclusively owns the underlying `T`.
> /// - The `T` value is pinned.
> +#[repr(transparent)]
AFAIT this `#[repr(transparent)]` isn't actually needed.
> pub struct Owned<T: Ownable> {
> ptr: NonNull<T>,
> }
> @@ -185,3 +188,46 @@ fn drop(&mut self) {
> unsafe { T::release(self.ptr.as_mut()) };
> }
> }
> +
> +// SAFETY: We derive the pointer to `T` from a valid `T`, so the returned
> +// pointer satisfy alignment requirements of `T`.
> +unsafe impl<T: Ownable + 'static> ForeignOwnable for Owned<T> {
You should drop the `'static` bound and put where bound on the GAT below
instead. See how `Box` is doing it.
Best,
Gary
> + const FOREIGN_ALIGN: usize = core::mem::align_of::<Owned<T>>();
> +
> + type Borrowed<'a> = &'a T;
> + type BorrowedMut<'a> = Pin<&'a mut T>;
> +
> + #[inline]
> + fn into_foreign(self) -> *mut kernel::ffi::c_void {
> + let ptr = self.ptr.as_ptr().cast();
> + core::mem::forget(self);
> + ptr
> + }
> +
> + #[inline]
> + unsafe fn from_foreign(ptr: *mut kernel::ffi::c_void) -> Self {
> + Self {
> + // SAFETY: By function safety contract, `ptr` came from
> + // `into_foreign` and cannot be null.
> + ptr: unsafe { NonNull::new_unchecked(ptr.cast()) },
> + }
> + }
> +
> + #[inline]
> + unsafe fn borrow<'a>(ptr: *mut kernel::ffi::c_void) -> Self::Borrowed<'a> {
> + // SAFETY: By function safety requirements, `ptr` is valid for use as a
> + // reference for `'a`.
> + unsafe { &*ptr.cast() }
> + }
> +
> + #[inline]
> + unsafe fn borrow_mut<'a>(ptr: *mut kernel::ffi::c_void) -> Self::BorrowedMut<'a> {
> + // SAFETY: By function safety requirements, `ptr` is valid for use as a
> + // unique reference for `'a`.
> + let inner = unsafe { &mut *ptr.cast() };
> +
> + // SAFETY: We never move out of inner, and we do not hand out mutable
> + // references when `T: !Unpin`.
> + unsafe { Pin::new_unchecked(inner) }
> + }
> +}
^ permalink raw reply
* Re: [PATCH v17 02/10] rust: types: Add Ownable/Owned types
From: Alice Ryhl @ 2026-06-16 11: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, Oliver Mangold
In-Reply-To: <20260604-unique-ref-v17-2-7b4c3d2930b9@kernel.org>
On Thu, Jun 04, 2026 at 10:11:14PM +0200, Andreas Hindborg wrote:
> From: Asahi Lina <lina+kernel@asahilina.net>
>
> By analogy to `AlwaysRefCounted` and `ARef`, an `Ownable` type is a
> (typically C FFI) type that *may* be owned by Rust, but need not be. Unlike
> `AlwaysRefCounted`, this mechanism expects the reference to be unique
> within Rust, and does not allow cloning.
>
> Conceptually, this is similar to a `KBox<T>`, except that it delegates
> resource management to the `T` instead of using a generic allocator.
>
> [ om:
> - Split code into separate file and `pub use` it from types.rs.
> - Make from_raw() and into_raw() public.
> - Remove OwnableMut, and make DerefMut dependent on Unpin instead.
> - Usage example/doctest for Ownable/Owned.
> - Fixes to documentation and commit message.
> ]
>
> Link: https://lore.kernel.org/all/20250202-rust-page-v1-1-e3170d7fe55e@asahilina.net/
> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
> Co-developed-by: Oliver Mangold <oliver.mangold@pm.me>
> Signed-off-by: Oliver Mangold <oliver.mangold@pm.me>
> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> [ Andreas: Updated documentation, examples, and formatting. Change safety
> requirements, safety comments. Use a reference for `release`. ]
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Co-developed-by: Andreas Hindborg <a.hindborg@kernel.org>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Overall looks good to me, but two nits below. With them fixed:
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> +pub trait Ownable {
> + /// Tear down this `Ownable`.
> + ///
> + /// Implementers of `Ownable` can use this function to clean up the use of `Self`. This can
> + /// include freeing the underlying object.
> + ///
> + /// # Safety
> + ///
> + /// Callers must ensure that the caller has exclusive ownership of `T`, and this ownership can
> + /// be transferred to the `release` method.
> + unsafe fn release(&mut self);
I'd make this take a raw pointer because the pointer can be freed during
the execution of release(), which references don't allow.
> diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
> index 4329d3c2c2e5..4aec7b699269 100644
> --- a/rust/kernel/types.rs
> +++ b/rust/kernel/types.rs
> @@ -11,6 +11,17 @@
> };
> use pin_init::{PinInit, Wrapper, Zeroable};
>
> +pub use crate::{
> + owned::{
> + Ownable,
> + Owned, //
> + },
> + sync::aref::{
> + ARef,
> + AlwaysRefCounted, //
> + }, //
> +};
We removed the types::ARef re-export, so you shouldn't add it back.
Alice
^ permalink raw reply
* Re: [PATCH v17 01/10] rust: alloc: add `KBox::into_non_null`
From: Gary Guo @ 2026-06-16 11:52 UTC (permalink / raw)
To: Andreas Hindborg, Miguel Ojeda, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, 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
Cc: linux-kernel, rust-for-linux, linux-block, linux-security-module,
dri-devel, linux-fsdevel, linux-mm, linux-pm, linux-pci,
driver-core
In-Reply-To: <20260604-unique-ref-v17-1-7b4c3d2930b9@kernel.org>
On Thu Jun 4, 2026 at 9:11 PM BST, Andreas Hindborg wrote:
> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
> is a convenience wrapper around `Self::into_raw` for callers that need
> a `NonNull` pointer rather than a raw pointer.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/kernel/alloc/kbox.rs | 9 +++++++++
> 1 file changed, 9 insertions(+)
^ permalink raw reply
* Re: [PATCH v17 01/10] rust: alloc: add `KBox::into_non_null`
From: Alice Ryhl @ 2026-06-16 11:50 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
In-Reply-To: <20260604-unique-ref-v17-1-7b4c3d2930b9@kernel.org>
On Thu, Jun 04, 2026 at 10:11:13PM +0200, Andreas Hindborg wrote:
> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
> is a convenience wrapper around `Self::into_raw` for callers that need
> a `NonNull` pointer rather than a raw pointer.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-16 8:49 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <CAHC9VhQxHEuznN-xiMJ-LCsz2z-UB0ri6MeMn+Ajyn1WUTDNDw@mail.gmail.com>
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? Anyway, it would not be written in
stone, we can update Sashiko config with new PRs.
>
> --
> paul-moore.com
>
^ permalink raw reply
* [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
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