* [PATCH v2 0/3] keys: fix keyring assoc-array out-of-bounds read and index inconsistency
From: Michael Bommarito @ 2026-07-14 11:54 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen
Cc: Andrew Morton, Paul Moore, James Morris, Serge E . Hallyn,
keyrings, linux-security-module, linux-kernel
An unprivileged keyring whose keys collide through the description-chunk
path can drive assoc_array node splitting into an out-of-bounds slot write.
Patch 1 stops the out-of-bounds read in keyring_get_key_chunk(); patch 2
makes the chunk byte order agree with keyring_diff_objects(); patch 3 fixes
the shortcut-walk trim so the walk cannot be steered down the wrong
descendant.
v2 changes (patch 3 only; patches 1 and 2 are unchanged):
As sashiko pointed out, the v1 patch-3 guard (sc_level + CHUNK >
skip_to_level) fixed the word-aligned leak but wrongly fired for an
unaligned first word whose skip_to_level sits on the next chunk
boundary: shift = skip_to_level & CHUNK_MASK is then 0 and the trim clears
the whole dissimilarity word, making a differing shortcut compare equal. v2
keys the trim on the end of the chunk that contains sc_level,
round_down(sc_level, CHUNK) + CHUNK, which matches a brute-force oracle over
every sc_level/skip_to_level pair; the original round_up guard and the v1
guard each disagree with the oracle in one regime.
v1: https://lore.kernel.org/keyrings/20260712014500.480410-1-michael.bommarito@gmail.com/
Michael Bommarito (3):
keys: fix out-of-bounds read in keyring_get_key_chunk()
keys: make keyring key-chunk byte order agree with keyring_diff_objects()
assoc_array: trim the final shortcut word using the current chunk end
lib/assoc_array.c | 3 ++-
security/keys/keyring.c | 15 ++++++++-------
2 files changed, 10 insertions(+), 8 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH -next] ima: add cond_resched() in ima_calc_file_hash_tfm loop
From: cuigaosheng @ 2026-07-14 9:28 UTC (permalink / raw)
To: Roberto Sassu, lujialin4, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-integrity, linux-security-module
In-Reply-To: <8c757ecb48c7dd733eb10c3927e9db94cb056fb0.camel@huaweicloud.com>
On 2026/7/13 20:06, Roberto Sassu wrote:
> On Mon, 2026-07-13 at 11:10 +0000, Gaosheng Cui wrote:
>> When hashing large files, the while loop in ima_calc_file_hash_tfm
>> processes PAGE_SIZE chunks without any scheduling point, which can
>> cause soft lockup warnings:
>> watchdog: BUG: soft lockup - CPU#0 stuck for 50s!
>> Call Trace:
>> _sha256_update+0x12d/0x1a0
>> ima_calc_file_hash_tfm+0xfb/0x150
>> ima_calc_file_hash+0x6e/0x160
>> ima_collect_measurement+0x202/0x340
>> process_measurement+0x3a9/0xb30
>> ima_file_check+0x56/0xa0
>> do_open+0x11b/0x250
>> path_openat+0x10b/0x1d0
>> do_filp_open+0xa9/0x150
>> do_sys_openat2+0x223/0x2a0
>> __x64_sys_openat+0x54/0xa0
>> do_syscall_64+0x59/0x110
>> entry_SYSCALL_64_after_hwframe+0x78/0xe2
>>
>> Add cond_resched() at the end of each loop iteration to voluntarily
>> yield the CPU when needed.
>>
>> Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
>> Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
>> ---
>> security/integrity/ima/ima_crypto.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
>> index 0d72b48249ee..3b7d41a9fd18 100644
>> --- a/security/integrity/ima/ima_crypto.c
>> +++ b/security/integrity/ima/ima_crypto.c
>> @@ -233,6 +233,8 @@ static int ima_calc_file_hash_tfm(struct file *file,
>> rc = crypto_shash_update(shash, rbuf, rbuf_len);
>> if (rc)
>> break;
>> +
>> + cond_resched();
> I would recommend not doing at every loop but every 4 MB at least:
>
> if (IS_ALIGNED(offset, SZ_4M))
> cond_resched();
>
> Thanks
>
> Roberto
Thanks,
I've updated to patch v2，call cond_resched() every 4MB.
>> }
>> kfree(rbuf);
>> out:
> .
^ permalink raw reply
* Re: [PATCH -next,v2] ima: add cond_resched() in ima_calc_file_hash_tfm loop
From: Roberto Sassu @ 2026-07-14 9:26 UTC (permalink / raw)
To: Gaosheng Cui, lujialin4, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-integrity, linux-security-module
In-Reply-To: <20260714091708.2802272-1-cuigaosheng1@huawei.com>
On Tue, 2026-07-14 at 17:17 +0800, Gaosheng Cui wrote:
> When hashing large files, the while loop in ima_calc_file_hash_tfm
> processes PAGE_SIZE chunks without any scheduling point, which can
> cause soft lockup warnings:
> watchdog: BUG: soft lockup - CPU#0 stuck for 50s!
> Call Trace:
> _sha256_update+0x12d/0x1a0
> ima_calc_file_hash_tfm+0xfb/0x150
> ima_calc_file_hash+0x6e/0x160
> ima_collect_measurement+0x202/0x340
> process_measurement+0x3a9/0xb30
> ima_file_check+0x56/0xa0
> do_open+0x11b/0x250
> path_openat+0x10b/0x1d0
> do_filp_open+0xa9/0x150
> do_sys_openat2+0x223/0x2a0
> __x64_sys_openat+0x54/0xa0
> do_syscall_64+0x59/0x110
> entry_SYSCALL_64_after_hwframe+0x78/0xe2
>
> Call cond_resched() every 4MB to yield the CPU when needed, rather
> than at every loop iteration, to reduce overhead.
>
> Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
> Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
Thanks
Roberto
> ---
> v2: call cond_resched() every 4MB to yield the CPU when needed
> security/integrity/ima/ima_crypto.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
> index 0d72b48249ee..aab2349c0c33 100644
> --- a/security/integrity/ima/ima_crypto.c
> +++ b/security/integrity/ima/ima_crypto.c
> @@ -233,6 +233,9 @@ static int ima_calc_file_hash_tfm(struct file *file,
> rc = crypto_shash_update(shash, rbuf, rbuf_len);
> if (rc)
> break;
> +
> + if (IS_ALIGNED(offset, SZ_4M))
> + cond_resched();
> }
> kfree(rbuf);
> out:
^ permalink raw reply
* [PATCH -next,v2] ima: add cond_resched() in ima_calc_file_hash_tfm loop
From: Gaosheng Cui @ 2026-07-14 9:17 UTC (permalink / raw)
To: cuigaosheng1, lujialin4, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-integrity, linux-security-module
When hashing large files, the while loop in ima_calc_file_hash_tfm
processes PAGE_SIZE chunks without any scheduling point, which can
cause soft lockup warnings:
watchdog: BUG: soft lockup - CPU#0 stuck for 50s!
Call Trace:
_sha256_update+0x12d/0x1a0
ima_calc_file_hash_tfm+0xfb/0x150
ima_calc_file_hash+0x6e/0x160
ima_collect_measurement+0x202/0x340
process_measurement+0x3a9/0xb30
ima_file_check+0x56/0xa0
do_open+0x11b/0x250
path_openat+0x10b/0x1d0
do_filp_open+0xa9/0x150
do_sys_openat2+0x223/0x2a0
__x64_sys_openat+0x54/0xa0
do_syscall_64+0x59/0x110
entry_SYSCALL_64_after_hwframe+0x78/0xe2
Call cond_resched() every 4MB to yield the CPU when needed, rather
than at every loop iteration, to reduce overhead.
Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
---
v2: call cond_resched() every 4MB to yield the CPU when needed
security/integrity/ima/ima_crypto.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 0d72b48249ee..aab2349c0c33 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -233,6 +233,9 @@ static int ima_calc_file_hash_tfm(struct file *file,
rc = crypto_shash_update(shash, rbuf, rbuf_len);
if (rc)
break;
+
+ if (IS_ALIGNED(offset, SZ_4M))
+ cond_resched();
}
kfree(rbuf);
out:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/3] keys: fix keyring assoc-array out-of-bounds read and index inconsistency
From: Andrew Morton @ 2026-07-14 2:11 UTC (permalink / raw)
To: Michael Bommarito
Cc: David Howells, Jarkko Sakkinen, Paul Moore, James Morris,
Serge E . Hallyn, keyrings, linux-security-module, linux-kernel
In-Reply-To: <20260712014500.480410-1-michael.bommarito@gmail.com>
On Sat, 11 Jul 2026 21:44:57 -0400 Michael Bommarito <michael.bommarito@gmail.com> wrote:
> keyring_get_key_chunk() advances the description read pointer by
> level * sizeof(long) past the inline prefix but only bounds-checks the
> prefix, so once the associative-array walk reaches a description-level
> chunk it reads past the kmemdup(desc, desc_len + 1) description
> allocation. Reaching that depth needs two keys that collide through the
> hash, x, type and domain_tag chunks, which an unprivileged add_key(2)
> can arrange with a crafted pair of same-type keys.
>
> An unprivileged user can thus read up to sizeof(long) bytes past a
> keyring key's description; on kernels built without init-on-alloc the
> same collision, read back with KEYCTL_READ, returns uninitialized kernel
> slab.
>
> Patch 1 is the memory-safety fix and stands alone. Patches 2 and 3 fix
> two index-key consistency bugs that let the crafted keys collide into a
> single malformed node in the first place, which is what enables the
> KEYCTL_READ disclosure.
>
> The KASAN reproduction is on patch 1. Trigger is available off-list.
fyi, AI review might have found things, some pre-existing:
https://sashiko.dev/#/patchset/20260712014500.480410-1-michael.bommarito@gmail.com
David, you might wish to take a look at the first assoc_array.c issue.
^ permalink raw reply
* [PATCH 2/2] doc: LSM: fix module ordering description for /sys/kernel/security/lsm
From: Lincoln Wallace @ 2026-07-14 1:38 UTC (permalink / raw)
To: paul, corbet
Cc: skhan, linux-doc, linux-kernel, linux-security-module,
penguin-kernel, rdunlap, Lincoln Wallace
In-Reply-To: <20260714013832.977443-1-locnnil0@gmail.com>
The LSM usage document states that the capability module will always
be first in /sys/kernel/security/lsm, followed by any "minor" modules
and then the one "major" module.
This does not match the current LSM infrastructure:
- When CONFIG_SECURITY_LOCKDOWN_LSM_EARLY is enabled, lockdown is
initialized as an early LSM, before all other modules including
capability, and appears first in the list.
- The integrity modules (e.g. IMA and EVM) register with
LSM_ORDER_LAST and are always placed at the end of the list,
regardless of the position of the major module.
- The relative order of the remaining modules is not fixed by the
framework; it follows CONFIG_LSM or the "lsm=" kernel command
line parameter.
Rewrite the paragraph to describe the actual ordering: lockdown
first when early lockdown is enabled, capability otherwise,
integrity modules at the end, and the remaining modules in the
configured order.
Signed-off-by: Lincoln Wallace <locnnil0@gmail.com>
---
Documentation/admin-guide/LSM/index.rst | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/LSM/index.rst b/Documentation/admin-guide/LSM/index.rst
index c24310c709dc..9518495edfbc 100644
--- a/Documentation/admin-guide/LSM/index.rst
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -27,9 +27,15 @@ man-pages project.
A list of the active security modules can be found by reading
``/sys/kernel/security/lsm``. This is a comma separated list, and
will always include the capability module. The list reflects the
-order in which checks are made. The capability module will always
-be first, followed by any "minor" modules (e.g. Yama) and then
-the one "major" module (e.g. SELinux) if there is one configured.
+order in which checks are made. The capability module will be
+first, unless CONFIG_SECURITY_LOCKDOWN_LSM_EARLY is enabled, in
+which case the lockdown module will precede it. The integrity
+modules (e.g. IMA and EVM), if enabled in the kernel
+configuration, are always placed at the end of the list. Any
+other "minor" modules (e.g. Yama) and the one "major" module
+(e.g. SELinux), if there is one configured, appear in between,
+in the order given by CONFIG_LSM or the ``"lsm=..."`` kernel
+command line parameter.
Process attributes associated with "major" security modules should
be accessed and maintained using the special files in ``/proc/.../attr``.
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] doc: LSM: describe CONFIG_LSM and lsm= as the selection mechanism
From: Lincoln Wallace @ 2026-07-14 1:38 UTC (permalink / raw)
To: paul, corbet
Cc: skhan, linux-doc, linux-kernel, linux-security-module,
penguin-kernel, rdunlap, Lincoln Wallace
In-Reply-To: <20260714013832.977443-1-locnnil0@gmail.com>
The LSM usage document states that security modules are selectable at
build time via CONFIG_DEFAULT_SECURITY and can be overridden at boot
time via the "security=..." kernel command line argument.
CONFIG_DEFAULT_SECURITY no longer exists: LSMs are enabled via
CONFIG_LSM, an ordered list of the LSMs to initialize, which can be
overridden at boot time with the "lsm=" parameter. The "security="
parameter remains as a deprecated way to choose a legacy "major"
security module, and is ignored when "lsm=" is specified; see commit
89a9684ea158 ("LSM: Ignore "security=" when "lsm=" is specified").
A previous attempt replaced "security=" with "lsm=" in place [1],
which was rejected because the parameters are not equivalent:
"security=" selects a single major module while the built-in
CONFIG_LSM list otherwise remains active, whereas "lsm=" must list
every LSM to enable.
Update the paragraph to describe CONFIG_LSM and "lsm=" as the current
selection mechanism, keeping "security=" documented as the deprecated
legacy option, matching the wording in kernel-parameters.txt.
Link: https://lore.kernel.org/r/20250114225156.10458-1-rdunlap@infradead.org [1]
Signed-off-by: Lincoln Wallace <locnnil0@gmail.com>
---
Documentation/admin-guide/LSM/index.rst | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/LSM/index.rst b/Documentation/admin-guide/LSM/index.rst
index b44ef68f6e4d..c24310c709dc 100644
--- a/Documentation/admin-guide/LSM/index.rst
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -6,9 +6,11 @@ The Linux Security Module (LSM) framework provides a mechanism for
various security checks to be hooked by new kernel extensions. The name
"module" is a bit of a misnomer since these extensions are not actually
loadable kernel modules. Instead, they are selectable at build-time via
-CONFIG_DEFAULT_SECURITY and can be overridden at boot-time via the
-``"security=..."`` kernel command line argument, in the case where multiple
-LSMs were built into a given kernel.
+CONFIG_LSM, an ordered list of the LSMs to enable, and can be
+overridden at boot-time via the ``"lsm=..."`` kernel command line
+argument. The ``"security=..."`` kernel command line argument remains
+available to choose a legacy "major" security module, but has been
+deprecated by the ``"lsm=..."`` parameter.
The primary users of the LSM interface are Mandatory Access Control
(MAC) extensions which provide a comprehensive security policy. Examples
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] doc: LSM: update usage document for current LSM stacking
From: Lincoln Wallace @ 2026-07-14 1:38 UTC (permalink / raw)
To: paul, corbet
Cc: skhan, linux-doc, linux-kernel, linux-security-module,
penguin-kernel, rdunlap, Lincoln Wallace
The LSM usage document (Documentation/admin-guide/LSM/index.rst) has
not kept up with the LSM stacking infrastructure. It still describes
CONFIG_DEFAULT_SECURITY, which no longer exists, and its description
of the module ordering in /sys/kernel/security/lsm does not match
what the framework actually does.
Patch 1 updates the selection mechanism description to CONFIG_LSM and
the "lsm=" parameter, keeping "security=" documented as the deprecated
legacy option. This revisits an earlier attempt by Randy Dunlap [1]
that was rejected for treating the two parameters as equivalent; the
new text keeps them distinct.
Patch 2 fixes the ordering description: lockdown precedes capability
when CONFIG_SECURITY_LOCKDOWN_LSM_EARLY is enabled, the integrity
modules are always placed at the end of the list, and the remaining
modules follow the order given by CONFIG_LSM or "lsm=".
[1] https://lore.kernel.org/r/20250114225156.10458-1-rdunlap@infradead.org
Lincoln Wallace (2):
doc: LSM: describe CONFIG_LSM and lsm= as the selection mechanism
doc: LSM: fix module ordering description for /sys/kernel/security/lsm
Documentation/admin-guide/LSM/index.rst | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v2 0/7] fs/9p: Reuse inode based on path (in addition to qid)
From: Tingmao Wang @ 2026-07-14 1:14 UTC (permalink / raw)
To: Greg Kurz, Christian Schoenebeck, Mickaël Salaün,
Dominique Martinet
Cc: qemu-devel, Eric Van Hensbergen, Latchesar Ionkov, v9fs,
Günther Noack, linux-security-module, Jan Kara,
Amir Goldstein, Matthew Bobrowski, Al Viro, Christian Brauner,
linux-fsdevel, Justin Suess
In-Reply-To: <20251013112424.6b93659c@bahia>
Hi Christian, Greg, Dominique,
Trying to revive this discussion, some answers to Greg's questions below,
then more thoughts on this series and alternatives.
On 10/13/25 10:24, Greg Kurz wrote:
> On Mon, 29 Sep 2025 15:06:59 +0200
> Christian Schoenebeck <linux_oss@crudebyte.com> wrote:
>
>> On Sunday, September 21, 2025 6:24:49 PM CEST Tingmao Wang wrote:
>>> On 9/17/25 16:00, Mickaël Salaün wrote:
>> [...]
>>
>> Hi Greg,
>>
>
> Hi Christian,
>
>> I'd appreciate comments from your side as well, as you are much on longer on
>> the QEMU 9p front than me.
>>
>> I know you won't have the time to read up on the entire thread so I try to
>> summarize: basically this is yet another user-after-unlink issue, this time on
>> directories instead of files.
>>
>
> Thread that never landed in my mailbox actually and it is quite
> hard to understand the root problem with the content of this
> e-mail actually ;-)
>
>>> So I did some quick debugging and realized that I had a wrong
>>> understanding of how fids relates to opened files on the host, under QEMU.
>>> It turns out that in QEMU's 9p server implementation, a fid does not
>>> actually correspond to any opened file descriptors - it merely represents
>>> a (string-based) path that QEMU stores internally. It only opens the
>>> actual file if the client actually does an T(l)open, which is in fact
>>> separate from acquiring the fid with T(l)walk. The reason why renaming
>>> file/dirs from the client doesn't break those fids is because QEMU will
>>> actually fix those paths when a rename request is processed - c.f.
>>> v9fs_fix_fid_paths [1].
>>
>> Correct, that's based on what the 9p protocols define: a FID does not exactly
>> translate to what a file handle is on a local system. Even after acquiring a
>> new FID by sending a Twalk request, subsequently client would still need to
>> send a Topen for server to actually open that file/directory.
>>
>> And yes, QEMU's 9p server "fixes" the path string of a FID if it was moved
>> upon client request. If the move happened on host side, outside of server's
>> knowledge, then this won't happen ATM and hence it would break your use
>> case.
>>
>>> It turns out that even if a guest process opens the file with O_PATH, that
>>> file descriptor does not cause an actual Topen, and therefore QEMU does
>>> not open the file on the host, and later on reopening that fd with another
>>> mode (via e.g. open("/proc/self/fd/...", O_RDONLY)) will fail if the file
>>> has moved on the host without QEMU's knowledge. Also, openat will fail if
>>> provided with a dir fd that "points" to a moved directory, regardless of
>>> whether the fd is opened with O_PATH or not, since path walk in QEMU is
>>> completely string-based and does not actually issue openat on the host fs
>>> [2].
>>
>> I don't think the problem here is the string based walk per se, but rather
>> that the string based walk always starts from the export root:
>>
>> https://github.com/qemu/qemu/blob/4975b64efb5aa4248cbc3760312bbe08d6e71638/hw/9pfs/9p-local.c#L64
>>
>> I guess that's something that could be changed in QEMU such that the walk
>> starts from FID's fs point, as the code already uses openat() to walk relative
>> to a file descriptor (for security reasons actually), Greg?
>>
>
> Yes this was introduced for security reasons. In a nutshell, the idea is
> to *not* follow symlinks in any element of the path being opened. It thus
> naturally starts at the export root for which we have an fd.
>
>> That alone would still not fix your use case though: things being moved on
>> host side. For this to work, it would require to already have a fd open on
>> host for the FID. This could be done by server for each FID as you suggested,
>> or it could be done by client by opening the FID.
>>
>
> Can you elaborate on the "things being move on host side" ? With
> an example of code that breaks on the client side ?
There are two cases where things break: openat() with a previously opened
dir fd, and re-open()ing an O_PATH fd as readable or writable with
/proc/self/fd.
For the first case,
https://fileshare.maowtm.org/9pfs-landlock-fix/20250921/openat.c
is an example program that demonstrates that in QEMU, path walk always
starts from the export root. The breakage is when the dir is moved on the
host, even if the file still exists within the dir with the same name, the
openat() with the opened dir fd (which translates to a fid in v9fs)
breaks:
(Host tmpfs exported as 9p to guest /tmp/9p)
root@7-2-0-rc2-dev:/# ./openat /tmp/9p/dir file
[ 12.264880][ T183] 9pnet: (00000183) >>> TWALK fids 1,2 nwname 1d wname[0] dir
[ 12.265156][ T183] 9pnet: (00000183) >>> size=22 type: 110 tag: 0
[ 12.265466][ T183] 9pnet: (00000183) <<< size=22 type: 111 tag: 0
[ 12.265590][ T183] 9pnet: (00000183) <<< RWALK nwqid 1:
[ 12.265675][ T183] 9pnet: (00000183) <<< [0] 80.6d10.6a53fe73
[ 12.265781][ T183] 9pnet: (00000183) >>> TGETATTR fid 2, request_mask 6143
[ 12.265903][ T183] 9pnet: (00000183) >>> size=19 type: 24 tag: 0
[ 12.266062][ T183] 9pnet: (00000183) <<< size=160 type: 25 tag: 0
[ 12.266148][ T183] 9pnet: (00000183) <<< RGETATTR st_result_mask=6143
[ 12.266148][ T183] <<< qid=80.6d10.6a53fe73
[ 12.266148][ T183] <<< st_mode=000041e8 st_nlink=2
[ 12.266148][ T183] <<< st_uid=1000 st_gid=1000
[ 12.266148][ T183] <<< st_rdev=0 st_size=3c st_blksize=131072 st_blocks=0
[ 12.266148][ T183] <<< st_atime_sec=1783874216 st_atime_nsec=302475718
[ 12.266148][ T183] <<< st_mtime_sec=1783874163 st_mtime_nsec=254338030
[ 12.266148][ T183] <<< st_ctime_sec=1783874163 st_ctime_nsec=254338030
[ 12.266148][ T183] <<< st_btime_sec=0 st_btime_nsec=0
[ 12.266148][ T183] <<< st_gen=0 st_data_version=0
[ 12.266932][ T183] 9pnet: (00000183) >>> TWALK fids 2,3 nwname 0d wname[0] (null)
[ 12.267038][ T183] 9pnet: (00000183) >>> size=17 type: 110 tag: 0
[ 12.267189][ T183] 9pnet: (00000183) <<< size=9 type: 111 tag: 0
[ 12.267300][ T183] 9pnet: (00000183) <<< RWALK nwqid 0:
[ 12.267368][ T183] 9pnet: (00000183) >>> TLOPEN fid 3 mode 98304
[ 12.267530][ T183] 9pnet: (00000183) >>> size=15 type: 12 tag: 0
[ 12.267779][ T183] 9pnet: (00000183) <<< size=24 type: 13 tag: 0
[ 12.267867][ T183] 9pnet: (00000183) <<< RLOPEN qid 80.6d10.6a53fe73 iounit 0
Opened /tmp/9p/dir with fd 3
[ 12.268713][ T183] 9pnet: (00000183) >>> TWALK fids 2,4 nwname 1d wname[0] file
[ 12.268816][ T183] 9pnet: (00000183) >>> size=23 type: 110 tag: 0
[ 12.268961][ T183] 9pnet: (00000183) <<< size=22 type: 111 tag: 0
[ 12.269051][ T183] 9pnet: (00000183) <<< RWALK nwqid 1:
[ 12.269116][ T183] 9pnet: (00000183) <<< [0] 0.6d11.6a53c273
[ 12.269198][ T183] 9pnet: (00000183) >>> TGETATTR fid 4, request_mask 6143
[ 12.269305][ T183] 9pnet: (00000183) >>> size=19 type: 24 tag: 0
[ 12.269454][ T183] 9pnet: (00000183) <<< size=160 type: 25 tag: 0
[ 12.269538][ T183] 9pnet: (00000183) <<< RGETATTR st_result_mask=6143
[ 12.269538][ T183] <<< qid=0.6d11.6a53c273
[ 12.269538][ T183] <<< st_mode=000081a0 st_nlink=1
[ 12.269538][ T183] <<< st_uid=1000 st_gid=1000
[ 12.269538][ T183] <<< st_rdev=0 st_size=0 st_blksize=131072 st_blocks=0
[ 12.269538][ T183] <<< st_atime_sec=1783874265 st_atime_nsec=602603686
[ 12.269538][ T183] <<< st_mtime_sec=1783874163 st_mtime_nsec=254338030
[ 12.269538][ T183] <<< st_ctime_sec=1783874163 st_ctime_nsec=254338030
[ 12.269538][ T183] <<< st_btime_sec=0 st_btime_nsec=0
[ 12.269538][ T183] <<< st_gen=0 st_data_version=0
[ 12.270149][ T183] 9pnet: (00000183) >>> TWALK fids 4,5 nwname 0d wname[0] (null)
[ 12.270249][ T183] 9pnet: (00000183) >>> size=17 type: 110 tag: 0
[ 12.270406][ T183] 9pnet: (00000183) <<< size=9 type: 111 tag: 0
[ 12.270497][ T183] 9pnet: (00000183) <<< RWALK nwqid 0:
[ 12.270561][ T183] 9pnet: (00000183) >>> TLOPEN fid 5 mode 32768
[ 12.270696][ T183] 9pnet: (00000183) >>> size=15 type: 12 tag: 0
[ 12.270879][ T183] 9pnet: (00000183) <<< size=24 type: 13 tag: 0
[ 12.270962][ T183] 9pnet: (00000183) <<< RLOPEN qid 0.6d11.6a53c273 iounit 20000
Opened file with fd 4
[ 12.271278][ T183] 9pnet: (00000183) >>> TREAD fid 5 offset 0 255
[ 12.271393][ T183] 9pnet: (00000183) >>> size=23 type: 116 tag: 0
[ 12.271577][ T183] 9pnet: (00000183) <<< size=11 type: 117 tag: 0
[ 12.271667][ T183] 9pnet: (00000183) <<< RREAD count 0
Read 0 bytes:
[ 12.271843][ T183] 9pnet: (00000183) >>> TCLUNK fid 5 (try 0)
[ 12.271978][ T183] 9pnet: (00000183) >>> size=11 type: 120 tag: 0
[ 12.272128][ T183] 9pnet: (00000183) <<< size=7 type: 121 tag: 0
[ 12.272212][ T183] 9pnet: (00000183) <<< RCLUNK fid 5
[ 12.272309][ T183] 9pnet: (00000183) >>> TCLUNK fid 4 (try 0)
[ 12.272407][ T183] 9pnet: (00000183) >>> size=11 type: 120 tag: 0
[ 12.272535][ T183] 9pnet: (00000183) <<< size=7 type: 121 tag: 0
[ 12.272618][ T183] 9pnet: (00000183) <<< RCLUNK fid 4
Press Enter to openat again or Ctrl-C to exit
(at this point dir is moved to dir1 on the host, then Enter is pressed here)
[ 32.441881][ T183] 9pnet: (00000183) >>> TWALK fids 2,4 nwname 1d wname[0] file
[ 32.442038][ T183] 9pnet: (00000183) >>> size=23 type: 110 tag: 0
[ 32.442330][ T183] 9pnet: (00000183) <<< size=11 type: 7 tag: 0
[ 32.442438][ T183] 9pnet: (00000183) <<< RLERROR (-2)
openat: No such file or directory
[ 32.443619][ T183] 9pnet: (00000183) >>> TCLUNK fid 3 (try 0)
[ 32.443790][ T183] 9pnet: (00000183) >>> size=11 type: 120 tag: 0
[ 32.443942][ T183] 9pnet: (00000183) <<< size=7 type: 121 tag: 0
[ 32.444037][ T183] 9pnet: (00000183) <<< RCLUNK fid 3
[ 32.444127][ T183] 9pnet: (00000183) >>> TCLUNK fid 2 (try 0)
[ 32.444235][ T183] 9pnet: (00000183) >>> size=11 type: 120 tag: 0
[ 32.444364][ T183] 9pnet: (00000183) <<< size=7 type: 121 tag: 0
[ 32.444450][ T183] 9pnet: (00000183) <<< RCLUNK fid 2
In this case QEMU does hold a fd for the dir (since the dir is opened with
O_RDONLY, causing a TLOPEN), but as Christian mentioned, it always starts
the path walk from root, rather than using that fd.
QEMU git commit a759542a2c (today's master)
For the second case,
https://fileshare.maowtm.org/9pfs-landlock-fix/20250921/open_procselffd.c
reproduces it:
(Host tmpfs exported as 9p to guest /tmp/9p)
root@7-2-0-rc2-dev:/# ./open_procselffd /tmp/9p/dir/file
[ 24.243001][ T188] 9pnet: (00000188) >>> TWALK fids 1,2 nwname 1d wname[0] dir
[ 24.243305][ T188] 9pnet: (00000188) >>> size=22 type: 110 tag: 0
[ 24.243659][ T188] 9pnet: (00000188) <<< size=22 type: 111 tag: 0
[ 24.243855][ T188] 9pnet: (00000188) <<< RWALK nwqid 1:
[ 24.243983][ T188] 9pnet: (00000188) <<< [0] 80.6d10.6a53fe73
[ 24.244124][ T188] 9pnet: (00000188) >>> TGETATTR fid 2, request_mask 6143
[ 24.244270][ T188] 9pnet: (00000188) >>> size=19 type: 24 tag: 0
[ 24.244460][ T188] 9pnet: (00000188) <<< size=160 type: 25 tag: 0
[ 24.244599][ T188] 9pnet: (00000188) <<< RGETATTR st_result_mask=6143
[ 24.244599][ T188] <<< qid=80.6d10.6a53fe73
[ 24.244599][ T188] <<< st_mode=000041e8 st_nlink=2
[ 24.244599][ T188] <<< st_uid=1000 st_gid=1000
[ 24.244599][ T188] <<< st_rdev=0 st_size=3c st_blksize=131072 st_blocks=0
[ 24.244599][ T188] <<< st_atime_sec=1783874216 st_atime_nsec=302475718
[ 24.244599][ T188] <<< st_mtime_sec=1783874163 st_mtime_nsec=254338030
[ 24.244599][ T188] <<< st_ctime_sec=1783875959 st_ctime_nsec=665487467
[ 24.244599][ T188] <<< st_btime_sec=0 st_btime_nsec=0
[ 24.244599][ T188] <<< st_gen=0 st_data_version=0
[ 24.245601][ T188] 9pnet: (00000188) >>> TWALK fids 2,3 nwname 1d wname[0] file
[ 24.245754][ T188] 9pnet: (00000188) >>> size=23 type: 110 tag: 0
[ 24.245936][ T188] 9pnet: (00000188) <<< size=22 type: 111 tag: 0
[ 24.246070][ T188] 9pnet: (00000188) <<< RWALK nwqid 1:
[ 24.246165][ T188] 9pnet: (00000188) <<< [0] 0.6d11.6a53c273
[ 24.246287][ T188] 9pnet: (00000188) >>> TGETATTR fid 3, request_mask 6143
[ 24.246484][ T188] 9pnet: (00000188) >>> size=19 type: 24 tag: 0
[ 24.246661][ T188] 9pnet: (00000188) <<< size=160 type: 25 tag: 0
[ 24.246780][ T188] 9pnet: (00000188) <<< RGETATTR st_result_mask=6143
[ 24.246780][ T188] <<< qid=0.6d11.6a53c273
[ 24.246780][ T188] <<< st_mode=000081a0 st_nlink=1
[ 24.246780][ T188] <<< st_uid=1000 st_gid=1000
[ 24.246780][ T188] <<< st_rdev=0 st_size=0 st_blksize=131072 st_blocks=0
[ 24.246780][ T188] <<< st_atime_sec=1783875507 st_atime_nsec=502397563
[ 24.246780][ T188] <<< st_mtime_sec=1783874163 st_mtime_nsec=254338030
[ 24.246780][ T188] <<< st_ctime_sec=1783874163 st_ctime_nsec=254338030
[ 24.246780][ T188] <<< st_btime_sec=0 st_btime_nsec=0
[ 24.246780][ T188] <<< st_gen=0 st_data_version=0
Opened /tmp/9p/dir/file with fd 3 (O_PATH)
Press Enter to reopen
(at this point dir/file is moved to dir/file2 on the host, then Enter is pressed here)
(result is the same if instead dir is renamed)
[ 34.725233][ T188] 9pnet: (00000188) >>> TWALK fids 3,4 nwname 0d wname[0] (null)
[ 34.725619][ T188] 9pnet: (00000188) >>> size=17 type: 110 tag: 0
[ 34.726067][ T188] 9pnet: (00000188) <<< size=11 type: 7 tag: 0
[ 34.726241][ T188] 9pnet: (00000188) <<< RLERROR (-2)
Failed to open /proc/self/fd/3: No such file or directory
Press Enter to exit
With this case, there is no TLOPEN, only TWALK, so QEMU does not hold a fd
for the file. (This means that, for Landlock, merely holding a fid is not
enough to prevent inode number reuse on QEMU)
>
>> Also keep in mind: once the open file descriptor limit on host is exhausted,
>> QEMU is forced to close older open file desciptors to keep the QEMU process
>> alive. So this might still break what you are trying to achieve there.
>>
>
> Correct.
>
>> Having said that, I wonder whether it'd be simpler for server to track for
>> file tree changes (inotify API) and fix the pathes accordingly for host
>> side changes as well?
>>
>
> The problem is how to have the guest know about such changes, e.g. in
> order to invalidate a stale cache entry. 9P doesn't provide any way for
> host->client notification.
I think there are two separate problems here - the server using inotify to
"fixup" its own tracked path of each fids, and the client being notified
of changes. With what Christian suggested, the above two cases will not
break even without any client notification, since the client (in this case
the kernel) already re-uses previously obtained fids to avoid redoing the
path walk from root.
Having client notification might be useful for other cases tho. Aside
from supporting things like inotify triggered from server-side
notification, it also looks like if a fd is passed to another user, on
access=user or access=client 9pfs will in fact re-do the path walk from
root (v9fs_fid_lookup_with_uid), and so having notification could let us
know what the expected path has changed to in order to correctly re-open a
(stale) dentry that may have been moved on the host.
>
>> /Christian
>>
>>
>
> Cheers,
>
I think overall there are still largely two directions, and I'm unclear
which way is best, but some recent testing has made me realize that the
second approach might be simpler than I thought:
- One is to continue with this path-based approach implemented in this RFC
series. The main issue I can see of doing this is the somewhat unwieldy
path tracking, and handling of parent renames (with the current
implementation it would need to recursively update all child ino_paths).
However, from a correctness point of view, inodeident=path proposed here
really means that both the path, qid.path, and inode type has to match,
and so the risk of "false inode matches" like the kind observed earlier,
leading to the revert of 724a08450f74 ("fs/9p: simplify iget to remove
unnecessary paths") and various related commits, should be low.
This also has the benefit of making i/fanotify on a cache=none 9pfs work
again (for local changes), aside from Landlock.
- The other is to have special handling in Landlock: Landlock would key
its rules on 9pfs based on some 9p-exposed identifier, such as the
fhandle as proposed by Dominique. Through testing I realized that we
could use st_gen to distinguish inodes with the same ino, and QEMU does
expose the st_gen to the guest when the backing fs is something like
ext4, so in fact this approach might be simplified (although I've only
realized this today and probably need to try this out on more
filesystems):
v qid.path
vvvvvvvv qid.version aka mtime
[ 78.617306][ T183] <<< qid=0.e.6a558647
[ 78.617306][ T183] <<< st_mode=000081a0 st_nlink=1
[ 78.617306][ T183] <<< st_uid=1000 st_gid=1000
[ 78.617306][ T183] <<< st_rdev=0 st_size=0 st_blksize=131072 st_blocks=0
[ 78.617306][ T183] <<< st_atime_sec=1783989831 st_atime_nsec=576593826
[ 78.617306][ T183] <<< st_mtime_sec=1783989831 st_mtime_nsec=576593826
[ 78.617306][ T183] <<< st_ctime_sec=1783989831 st_ctime_nsec=576593826
[ 78.617306][ T183] <<< st_btime_sec=0 st_btime_nsec=0
[ 78.617306][ T183] <<< st_gen=3634407333 st_data_version=0
After rm + touch:
v qid.path
vvvvvvvv qid.version aka mtime
[ 100.234598][ T184] <<< qid=0.e.6a558659
[ 100.234598][ T184] <<< st_mode=000081a0 st_nlink=1
[ 100.234598][ T184] <<< st_uid=1000 st_gid=1000
[ 100.234598][ T184] <<< st_rdev=0 st_size=0 st_blksize=131072 st_blocks=0
[ 100.234598][ T184] <<< st_atime_sec=1783989849 st_atime_nsec=5600077
[ 100.234598][ T184] <<< st_mtime_sec=1783989849 st_mtime_nsec=5600077
[ 100.234598][ T184] <<< st_ctime_sec=1783989849 st_ctime_nsec=5600077
[ 100.234598][ T184] <<< st_btime_sec=0 st_btime_nsec=0
[ 100.234598][ T184] <<< st_gen=4062134779 st_data_version=0
^ this is different
Previously I proposed that Landlock would need to hold a fid to keep the
inode alive on the server side, to prevent inode number reuse when using
qid.path as the rule key, but if the 9pfs-exposed fhandle includes this
inode generation number, and Landlock uses that instead, then inode
reuse is no longer an issue, without Landlock having to do anything
special.
(we can't use qid.version since that is mtime, which will change on
modification / files added or removed in a directory)
Does anyone have preferences / suggestions on whether to keep going with
the path-tracking based approach (perhaps subject to figuring out a way to
handle parent renames), or an approach where Landlock simply stores the
fhandle (or (i_ino, i_generation (but this is u32 whereas st_gen within 9p
is u64))) as the rule key?
If I find some time over the next couple of weeks I will try out the
second approach since it might be turning out to be the simpler option,
but the drawback is that it doesn't enable i/fanotify on 9pfs, which I
originally hoped to achieve together with fixing Landlock on 9pfs.
Kind regards,
Tingmao
^ permalink raw reply
* Re: [PATCH 11/13 RFC net-next] net: cipso: guard IPv4 packet manipulation functions
From: Fernando Fernandez Mancera @ 2026-07-13 14:03 UTC (permalink / raw)
To: Paul Moore
Cc: netdev, davem, edumazet, kuba, pabeni, dsahern, horms, idosch,
linux-security-module, linux-kernel
In-Reply-To: <CAHC9VhTA8Y+BLOcLcv6X9u3nRU=X7NQz-u4kZuVNL-Yz1mWKxw@mail.gmail.com>
On 7/12/26 6:22 PM, Paul Moore wrote:
> On Sat, Jul 11, 2026 at 9:41 PM Fernando Fernandez Mancera
> <fmancera@suse.de> wrote:
>>
>> To enable compiling the network stack without IPv4, the CIPSO functions
>> that manipulate IPv4 options and generate ICMP errors must be bypassed.
>>
>> Ideally, CIPSO should not be compiled when IPv4 is disabled but
>> currently it is too integrated within netlabel, so let's just bypassed
>> the relevant functions.
>>
>> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
>> ---
>> net/ipv4/cipso_ipv4.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>
> I think I would prefer to make CONFIG_NETLABEL dependent on
> CONFIG_IPV4 at this point in time. This will keep the code cleaner
> and allow time to do the proper work of wrapping the CIPSO code with
> CONFIG_CIPSO (or similar) and making that dependent on CONFIG_IPV4.
>
Fair, that works for me too. I am gonna drop this on the v1.
Thank you!
Fernando.
^ permalink raw reply
* Re: [PATCH v3] hardening: Default randstruct off with rust for better allmodconfig support
From: Mark Brown @ 2026-07-13 14:02 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Gary Guo, Kees Cook, Gustavo A. R. Silva, Paul Moore,
James Morris, Serge E. Hallyn, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, linux-hardening,
linux-security-module, linux-kernel, rust-for-linux
In-Reply-To: <CANiq72kNYRBW88VwYyDX8_2b1L7dLv_gDwgE5SruMELR7KPmig@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
On Mon, Jul 13, 2026 at 03:58:11PM +0200, Miguel Ojeda wrote:
> On Mon, Jul 13, 2026 at 3:55 PM Gary Guo <gary@garyguo.net> wrote:
> > I thought Miguel wants to add support to properly support RANDSTRUCT with Clang?
It would be great to have randstruct support for clang and Rust but we
do not currently have that support.
> I am happy either way, i.e. whatever the hardening folks prefer, but
> regardless of what we do, I think recovering the linux-next coverage
> is a high priority at the moment.
Yeah, when randstruct support is added we can remove all the constraints
around it and clang/Rust - this patch is about the making the current
situation work more usefully, it's not intended to be a final state.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3] hardening: Default randstruct off with rust for better allmodconfig support
From: Miguel Ojeda @ 2026-07-13 13:58 UTC (permalink / raw)
To: Gary Guo
Cc: Mark Brown, Kees Cook, Gustavo A. R. Silva, Paul Moore,
James Morris, Serge E. Hallyn, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, linux-hardening,
linux-security-module, linux-kernel, rust-for-linux
In-Reply-To: <DJXHTB615I2J.POTXT6L2LM5K@garyguo.net>
On Mon, Jul 13, 2026 at 3:55 PM Gary Guo <gary@garyguo.net> wrote:
>
> I thought Miguel wants to add support to properly support RANDSTRUCT with Clang?
I am happy either way, i.e. whatever the hardening folks prefer, but
regardless of what we do, I think recovering the linux-next coverage
is a high priority at the moment.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v3] hardening: Default randstruct off with rust for better allmodconfig support
From: Gary Guo @ 2026-07-13 13:54 UTC (permalink / raw)
To: Mark Brown, Kees Cook, Gustavo A. R. Silva, Paul Moore,
James Morris, Serge E. Hallyn, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich
Cc: linux-hardening, linux-security-module, linux-kernel,
rust-for-linux
In-Reply-To: <7cdb2407-924c-44a1-8c68-917efadd4e92@sirena.org.uk>
On Mon Jul 13, 2026 at 1:45 PM BST, Mark Brown wrote:
> On Thu, Jul 02, 2026 at 06:37:08PM +0100, Mark Brown wrote:
>> Currently randstruct does not support rust so we have Kconfig dependencies
>> which prevent rust being enabled when randstruct is. Unfortunately this
>> prevents rust being enabled in allmodconfig, our standard coverage build.
>> randstruct gets turned on by default, then the dependency on !RANDSTRUCT
>> causes rust to get disabled.
>
> Any news on this? I'm flying blind doing -next merges of rust code with
> build coverage gone, and I suspect a bunch of other people think they
> have build coverage in their tests but it's silently vanished (I know at
> least one person ran into that already).
I thought Miguel wants to add support to properly support RANDSTRUCT with Clang?
Best,
Gary
^ permalink raw reply
* Re: [PATCH v3] hardening: Default randstruct off with rust for better allmodconfig support
From: Mark Brown @ 2026-07-13 12:45 UTC (permalink / raw)
To: Kees Cook, Gustavo A. R. Silva, Paul Moore, James Morris,
Serge E. Hallyn, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich
Cc: linux-hardening, linux-security-module, linux-kernel,
rust-for-linux
In-Reply-To: <20260702-rust-reverse-randstruct-dep-v3-1-e4e09c50014e@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
On Thu, Jul 02, 2026 at 06:37:08PM +0100, Mark Brown wrote:
> Currently randstruct does not support rust so we have Kconfig dependencies
> which prevent rust being enabled when randstruct is. Unfortunately this
> prevents rust being enabled in allmodconfig, our standard coverage build.
> randstruct gets turned on by default, then the dependency on !RANDSTRUCT
> causes rust to get disabled.
Any news on this? I'm flying blind doing -next merges of rust code with
build coverage gone, and I suspect a bunch of other people think they
have build coverage in their tests but it's silently vanished (I know at
least one person ran into that already).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH -next] ima: add cond_resched() in ima_calc_file_hash_tfm loop
From: Roberto Sassu @ 2026-07-13 12:06 UTC (permalink / raw)
To: Gaosheng Cui, lujialin4, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-integrity, linux-security-module
In-Reply-To: <20260713111022.2418849-1-cuigaosheng1@huawei.com>
On Mon, 2026-07-13 at 11:10 +0000, Gaosheng Cui wrote:
> When hashing large files, the while loop in ima_calc_file_hash_tfm
> processes PAGE_SIZE chunks without any scheduling point, which can
> cause soft lockup warnings:
> watchdog: BUG: soft lockup - CPU#0 stuck for 50s!
> Call Trace:
> _sha256_update+0x12d/0x1a0
> ima_calc_file_hash_tfm+0xfb/0x150
> ima_calc_file_hash+0x6e/0x160
> ima_collect_measurement+0x202/0x340
> process_measurement+0x3a9/0xb30
> ima_file_check+0x56/0xa0
> do_open+0x11b/0x250
> path_openat+0x10b/0x1d0
> do_filp_open+0xa9/0x150
> do_sys_openat2+0x223/0x2a0
> __x64_sys_openat+0x54/0xa0
> do_syscall_64+0x59/0x110
> entry_SYSCALL_64_after_hwframe+0x78/0xe2
>
> Add cond_resched() at the end of each loop iteration to voluntarily
> yield the CPU when needed.
>
> Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
> Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
> ---
> security/integrity/ima/ima_crypto.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
> index 0d72b48249ee..3b7d41a9fd18 100644
> --- a/security/integrity/ima/ima_crypto.c
> +++ b/security/integrity/ima/ima_crypto.c
> @@ -233,6 +233,8 @@ static int ima_calc_file_hash_tfm(struct file *file,
> rc = crypto_shash_update(shash, rbuf, rbuf_len);
> if (rc)
> break;
> +
> + cond_resched();
I would recommend not doing at every loop but every 4 MB at least:
if (IS_ALIGNED(offset, SZ_4M))
cond_resched();
Thanks
Roberto
> }
> kfree(rbuf);
> out:
^ permalink raw reply
* [PATCH -next] ima: add cond_resched() in ima_calc_file_hash_tfm loop
From: Gaosheng Cui @ 2026-07-13 11:10 UTC (permalink / raw)
To: cuigaosheng1, lujialin4, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-integrity, linux-security-module
When hashing large files, the while loop in ima_calc_file_hash_tfm
processes PAGE_SIZE chunks without any scheduling point, which can
cause soft lockup warnings:
watchdog: BUG: soft lockup - CPU#0 stuck for 50s!
Call Trace:
_sha256_update+0x12d/0x1a0
ima_calc_file_hash_tfm+0xfb/0x150
ima_calc_file_hash+0x6e/0x160
ima_collect_measurement+0x202/0x340
process_measurement+0x3a9/0xb30
ima_file_check+0x56/0xa0
do_open+0x11b/0x250
path_openat+0x10b/0x1d0
do_filp_open+0xa9/0x150
do_sys_openat2+0x223/0x2a0
__x64_sys_openat+0x54/0xa0
do_syscall_64+0x59/0x110
entry_SYSCALL_64_after_hwframe+0x78/0xe2
Add cond_resched() at the end of each loop iteration to voluntarily
yield the CPU when needed.
Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
---
security/integrity/ima/ima_crypto.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 0d72b48249ee..3b7d41a9fd18 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -233,6 +233,8 @@ static int ima_calc_file_hash_tfm(struct file *file,
rc = crypto_shash_update(shash, rbuf, rbuf_len);
if (rc)
break;
+
+ cond_resched();
}
kfree(rbuf);
out:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 11/13 RFC net-next] net: cipso: guard IPv4 packet manipulation functions
From: Paul Moore @ 2026-07-12 16:22 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, davem, edumazet, kuba, pabeni, dsahern, horms, idosch,
linux-security-module, linux-kernel
In-Reply-To: <20260712013941.4570-12-fmancera@suse.de>
On Sat, Jul 11, 2026 at 9:41 PM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
> To enable compiling the network stack without IPv4, the CIPSO functions
> that manipulate IPv4 options and generate ICMP errors must be bypassed.
>
> Ideally, CIPSO should not be compiled when IPv4 is disabled but
> currently it is too integrated within netlabel, so let's just bypassed
> the relevant functions.
>
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> ---
> net/ipv4/cipso_ipv4.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
I think I would prefer to make CONFIG_NETLABEL dependent on
CONFIG_IPV4 at this point in time. This will keep the code cleaner
and allow time to do the proper work of wrapping the CIPSO code with
CONFIG_CIPSO (or similar) and making that dependent on CONFIG_IPV4.
--
paul-moore.com
^ permalink raw reply
* [PATCH] apparmor: replace decompress_zstd() prototype with its entity
From: Tetsuo Handa @ 2026-07-12 10:17 UTC (permalink / raw)
To: Maxime Bélair, John Johansen; +Cc: linux-security-module
In-Reply-To: <83eb9325-9688-4a6c-9727-e137df773694@I-love.SAKURA.ne.jp>
Fix "undefined symbol: decompress_zstd" error caused by decompress_zstd()
being guarded by CONFIG_SECURITY_APPARMOR_EXPORT_BINARY=y.
Reported-by: syzbot+1f14a35d0c73d31555e4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1f14a35d0c73d31555e4
Fixes: 17b5758bf35c ("apparmor: Initial support for compressed policies")
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
security/apparmor/apparmorfs.c | 72 +++++++++++++++++-----------------
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
index 2ae9ab94a5a91..152c7967ff1ba 100644
--- a/security/apparmor/apparmorfs.c
+++ b/security/apparmor/apparmorfs.c
@@ -483,7 +483,42 @@ static struct aa_loaddata *aa_simple_write_to_buffer(const char __user *userbuf,
return data;
}
-static int decompress_zstd(char *src, size_t slen, char *dst, size_t dlen);
+
+static int decompress_zstd(char *src, size_t slen, char *dst, size_t dlen)
+{
+ if (slen < dlen) {
+ const size_t wksp_len = zstd_dctx_workspace_bound();
+ zstd_dctx *ctx;
+ void *wksp;
+ size_t out_len;
+ int ret = 0;
+
+ wksp = kvzalloc(wksp_len, GFP_KERNEL);
+ if (!wksp) {
+ ret = -ENOMEM;
+ goto cleanup;
+ }
+ ctx = zstd_init_dctx(wksp, wksp_len);
+ if (ctx == NULL) {
+ ret = -ENOMEM;
+ goto cleanup;
+ }
+ out_len = zstd_decompress_dctx(ctx, dst, dlen, src, slen);
+ if (zstd_is_error(out_len)) {
+ ret = -EINVAL;
+ goto cleanup;
+ }
+cleanup:
+ kvfree(wksp);
+ return ret;
+ }
+
+ if (dlen < slen)
+ return -EINVAL;
+ memcpy(dst, src, slen);
+ return 0;
+}
+
/**
* aa_get_data_from_compressed - common routine for getting compressed policy
* from user and get both compressed and uncompressed version.
@@ -1517,41 +1552,6 @@ SEQ_RAWDATA_FOPS(revision);
SEQ_RAWDATA_FOPS(hash);
SEQ_RAWDATA_FOPS(compressed_size);
-static int decompress_zstd(char *src, size_t slen, char *dst, size_t dlen)
-{
- if (slen < dlen) {
- const size_t wksp_len = zstd_dctx_workspace_bound();
- zstd_dctx *ctx;
- void *wksp;
- size_t out_len;
- int ret = 0;
-
- wksp = kvzalloc(wksp_len, GFP_KERNEL);
- if (!wksp) {
- ret = -ENOMEM;
- goto cleanup;
- }
- ctx = zstd_init_dctx(wksp, wksp_len);
- if (ctx == NULL) {
- ret = -ENOMEM;
- goto cleanup;
- }
- out_len = zstd_decompress_dctx(ctx, dst, dlen, src, slen);
- if (zstd_is_error(out_len)) {
- ret = -EINVAL;
- goto cleanup;
- }
-cleanup:
- kvfree(wksp);
- return ret;
- }
-
- if (dlen < slen)
- return -EINVAL;
- memcpy(dst, src, slen);
- return 0;
-}
-
static ssize_t rawdata_read(struct file *file, char __user *buf, size_t size,
loff_t *ppos)
{
--
2.52.0
^ permalink raw reply related
* [PATCH 3/3] assoc_array: trim the final shortcut word when skip_to_level is chunk-aligned
From: Michael Bommarito @ 2026-07-12 1:45 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen
Cc: Paul Moore, James Morris, Serge E . Hallyn, Andrew Morton,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <20260712014500.480410-1-michael.bommarito@gmail.com>
assoc_array_walk() masks off the bits past shortcut->skip_to_level in
the final word of a shortcut before testing it, gated on
round_up(sc_level, chunk_size) > skip_to_level. Once sc_level is
word-aligned (every word after the first) round_up() is a no-op and the
guard never fires for the word that contains skip_to_level, so its stale
high bits leak into the dissimilarity word and can steer the walk down
the wrong descendant.
Test sc_level + ASSOC_ARRAY_KEY_CHUNK_SIZE > skip_to_level directly; an
exact-multiple skip_to_level ends on the boundary and stays untrimmed.
Fixes: 3cb989501c26 ("Add a generic associative array implementation.")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
lib/assoc_array.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/assoc_array.c b/lib/assoc_array.c
index bcc6e0a013eb8..1de2c337f8fcf 100644
--- a/lib/assoc_array.c
+++ b/lib/assoc_array.c
@@ -255,7 +255,7 @@ assoc_array_walk(const struct assoc_array *array,
sc_segments = shortcut->index_key[sc_level >> ASSOC_ARRAY_KEY_CHUNK_SHIFT];
dissimilarity = segments ^ sc_segments;
- if (round_up(sc_level, ASSOC_ARRAY_KEY_CHUNK_SIZE) > shortcut->skip_to_level) {
+ if (sc_level + ASSOC_ARRAY_KEY_CHUNK_SIZE > shortcut->skip_to_level) {
/* Trim segments that are beyond the shortcut */
int shift = shortcut->skip_to_level & ASSOC_ARRAY_KEY_CHUNK_MASK;
dissimilarity &= ~(ULONG_MAX << shift);
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] keys: make keyring key-chunk byte order agree with keyring_diff_objects()
From: Michael Bommarito @ 2026-07-12 1:44 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen
Cc: Paul Moore, James Morris, Serge E . Hallyn, Andrew Morton,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <20260712014500.480410-1-michael.bommarito@gmail.com>
keyring_get_key_chunk() loads description bytes into the index chunk low
address first, while keyring_diff_objects() numbers the first differing
bit from the low end and folds the absolute byte index into the level
without removing the inline-prefix offset the level already carries.
The two disagree on byte order and bit position, so the array can be
told two keys first differ at a bit that does not differ in the chunk
the walker uses, letting crafted descriptions collide into one node.
Load the chunk in the order keyring_diff_objects() assumes and drop the
inline-prefix length when folding the byte index into the level. This
only changes the in-memory ordering used to place keys within a keyring;
add, search and read of non-colliding keys are unaffected.
Fixes: f771fde82051 ("keys: Simplify key description management")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
security/keys/keyring.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index 1739373172ad5..e7066893e6ffc 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -292,9 +292,10 @@ static unsigned long keyring_get_key_chunk(const void *data, int level)
desc_len -= offset;
if (desc_len > n)
desc_len = n;
+ d += desc_len;
do {
chunk <<= 8;
- chunk |= *d++;
+ chunk |= *--d;
} while (--desc_len > 0);
return chunk;
}
@@ -375,7 +376,7 @@ static int keyring_diff_objects(const void *object, const void *data)
return -1;
differ_plus_i:
- level += i;
+ level += i - (int)sizeof(a->desc);
differ:
i = level * 8 + __ffs(seg_a ^ seg_b);
return i;
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] keys: fix out-of-bounds read in keyring_get_key_chunk()
From: Michael Bommarito @ 2026-07-12 1:44 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen
Cc: Paul Moore, James Morris, Serge E . Hallyn, Andrew Morton,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <20260712014500.480410-1-michael.bommarito@gmail.com>
For description-level chunks keyring_get_key_chunk() advances the read
pointer by level * sizeof(long) past the inline prefix but only
bounds-checks the prefix, so a long enough key description is read past
its kmemdup(desc, desc_len + 1) allocation. Compute the full byte
offset and bounds-check the description against it before reading.
The walk only reaches a description-level chunk when two keys collide
through the hash, x, type and domain_tag chunks, so this is reached from
an unprivileged add_key(2) with a crafted pair of same-type keys whose
index hashes collide; KASAN reports a slab-out-of-bounds read.
Fixes: f771fde82051 ("keys: Simplify key description management")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
security/keys/keyring.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
KASAN, x86_64: add_key(2) of a crafted hash-colliding "user"-key pair
(~63-byte descriptions) reports
BUG: KASAN: slab-out-of-bounds in keyring_get_key_chunk
keyring_get_key_chunk <- assoc_array_insert <- __key_link_begin
<- __do_sys_add_key
reading one byte past the description allocation; the same trigger is
KASAN-clean with this patch. On a kernel built without init-on-alloc,
reading the colliding keyring back with KEYCTL_READ returns
uninitialized slab until patches 2 and 3 are applied too. Trigger
available off-list.
diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index 7a2ee0ded7c93..1739373172ad5 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -270,7 +270,7 @@ static unsigned long keyring_get_key_chunk(const void *data, int level)
const struct keyring_index_key *index_key = data;
unsigned long chunk = 0;
const u8 *d;
- int desc_len = index_key->desc_len, n = sizeof(chunk);
+ int desc_len = index_key->desc_len, n = sizeof(chunk), offset;
level /= ASSOC_ARRAY_KEY_CHUNK_SIZE;
switch (level) {
@@ -284,12 +284,12 @@ static unsigned long keyring_get_key_chunk(const void *data, int level)
return (unsigned long)index_key->domain_tag;
default:
level -= 4;
- if (desc_len <= sizeof(index_key->desc))
+ offset = sizeof(index_key->desc) + level * sizeof(long);
+ if (desc_len <= offset)
return 0;
- d = index_key->description + sizeof(index_key->desc);
- d += level * sizeof(long);
- desc_len -= sizeof(index_key->desc);
+ d = index_key->description + offset;
+ desc_len -= offset;
if (desc_len > n)
desc_len = n;
do {
--
2.53.0
^ permalink raw reply related
* [PATCH 0/3] keys: fix keyring assoc-array out-of-bounds read and index inconsistency
From: Michael Bommarito @ 2026-07-12 1:44 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen
Cc: Paul Moore, James Morris, Serge E . Hallyn, Andrew Morton,
keyrings, linux-security-module, linux-kernel
keyring_get_key_chunk() advances the description read pointer by
level * sizeof(long) past the inline prefix but only bounds-checks the
prefix, so once the associative-array walk reaches a description-level
chunk it reads past the kmemdup(desc, desc_len + 1) description
allocation. Reaching that depth needs two keys that collide through the
hash, x, type and domain_tag chunks, which an unprivileged add_key(2)
can arrange with a crafted pair of same-type keys.
An unprivileged user can thus read up to sizeof(long) bytes past a
keyring key's description; on kernels built without init-on-alloc the
same collision, read back with KEYCTL_READ, returns uninitialized kernel
slab.
Patch 1 is the memory-safety fix and stands alone. Patches 2 and 3 fix
two index-key consistency bugs that let the crafted keys collide into a
single malformed node in the first place, which is what enables the
KEYCTL_READ disclosure.
The KASAN reproduction is on patch 1. Trigger is available off-list.
Michael Bommarito (3):
keys: fix out-of-bounds read in keyring_get_key_chunk()
keys: make keyring key-chunk byte order agree with
keyring_diff_objects()
assoc_array: trim the final shortcut word when skip_to_level is
chunk-aligned
lib/assoc_array.c | 2 +-
security/keys/keyring.c | 15 ++++++++-------
2 files changed, 9 insertions(+), 8 deletions(-)
base-commit: 2c7c88a412aa6d09cd04b414211b4ef8553b5309
--
2.53.0
^ permalink raw reply
* [PATCH 11/13 RFC net-next] net: cipso: guard IPv4 packet manipulation functions
From: Fernando Fernandez Mancera @ 2026-07-12 1:39 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, dsahern, horms, idosch,
Fernando Fernandez Mancera, Paul Moore, linux-security-module,
linux-kernel
In-Reply-To: <20260712013941.4570-1-fmancera@suse.de>
To enable compiling the network stack without IPv4, the CIPSO functions
that manipulate IPv4 options and generate ICMP errors must be bypassed.
Ideally, CIPSO should not be compiled when IPv4 is disabled but
currently it is too integrated within netlabel, so let's just bypassed
the relevant functions.
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
net/ipv4/cipso_ipv4.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index a05aa075de1a..17bb723299d7 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1714,6 +1714,7 @@ int cipso_v4_validate(const struct sk_buff *skb, unsigned char **option)
*/
void cipso_v4_error(struct sk_buff *skb, int error, u32 gateway)
{
+#if IS_ENABLED(CONFIG_IPV4)
struct inet_skb_parm parm;
int res;
@@ -1738,6 +1739,7 @@ void cipso_v4_error(struct sk_buff *skb, int error, u32 gateway)
__icmp_send(skb, ICMP_DEST_UNREACH, ICMP_NET_ANO, 0, &parm);
else
__icmp_send(skb, ICMP_DEST_UNREACH, ICMP_HOST_ANO, 0, &parm);
+#endif
}
/**
@@ -2171,6 +2173,7 @@ int cipso_v4_skbuff_setattr(struct sk_buff *skb,
const struct cipso_v4_doi *doi_def,
const struct netlbl_lsm_secattr *secattr)
{
+#if IS_ENABLED(CONFIG_IPV4)
int ret_val;
struct iphdr *iph;
struct ip_options *opt = &IPCB(skb)->opt;
@@ -2235,6 +2238,9 @@ int cipso_v4_skbuff_setattr(struct sk_buff *skb,
ip_send_check(iph);
return 0;
+#else
+ return -EOPNOTSUPP;
+#endif
}
/**
@@ -2248,6 +2254,7 @@ int cipso_v4_skbuff_setattr(struct sk_buff *skb,
*/
int cipso_v4_skbuff_delattr(struct sk_buff *skb)
{
+#if IS_ENABLED(CONFIG_IPV4)
int ret_val, cipso_len, hdr_len_actual, new_hdr_len_actual, new_hdr_len,
hdr_len_delta;
struct iphdr *iph;
@@ -2296,6 +2303,9 @@ int cipso_v4_skbuff_delattr(struct sk_buff *skb)
ip_send_check(iph);
return 0;
+#else
+ return -EOPNOTSUPP;
+#endif
}
/*
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 0/3] Implement LANDLOCK_RESTRICT_SELF_NNP_ON_EXEC
From: Justin Suess @ 2026-07-11 17:00 UTC (permalink / raw)
To: Simon McVittie; +Cc: Mickaël Salaün, linux-security-module, gnoack
In-Reply-To: <ak-EgMPeFtH8MAQP@descent>
On Thu, Jul 09, 2026 at 12:22:40PM +0100, Simon McVittie wrote:
> On Thu, 09 Jul 2026 at 12:09:25 +0200, Mickaël Salaün wrote:
> > On Wed, Jul 08, 2026 at 09:39:24AM -0400, Justin Suess wrote:
> > > Consider a sandbox launcher that depends on a set-user-ID helper, such
> > > as launching applications through bubblewrap on distributions where
> > > unprivileged user namespaces are disabled and bwrap is installed
> > > set-user-ID root.
>
> It's perhaps worth noting that the current version 0.11.2 of bubblewrap
> deprecates this mode of use (it will refuse to run while setuid unless
> that was explicitly enabled at compile-time), and the next release 0.12.0
> will also remove the ability to enable it at compile-time.
>
> When bubblewrap was first written, having it be setuid was a necessary
> workaround for kernels/distros not letting it do its sandboxing job any
> other way; but now that unprivileged user namespaces are more widespread,
> its maintainers have come to the conclusion that when it's setuid,
> the risk of vulnerabilities that allow a root privilege escalation
> (CVE-2020-5291, CVE-2026-41163) is unacceptably high, so being able to
> make it setuid is no longer a good trade-off.
>
> > > This flag also closes a gap for CAP_SYS_ADMIN callers of
> > > landlock_restrict_self(2) itself. The no_new_privs/CAP_SYS_ADMIN
> > > requirement exists to keep set-user-ID programs from running confused
> > > inside a sandbox they do not expect. However, a privileged process
> > > that enforces a domain without setting no_new_privs leaves that hole
> > > open for all of its descendants
> >
> > In a nutshell, not setting NNP might be risky, even when not strictly
> > needed. We might want to update the Landlock doc with that.
>
> If the CAP_SYS_ADMIN caller is setuid or setcap, then it has been
> granted special privileges by the sysadmin or distro, and part of
> the "contract" between the sysadmin/distro and the setuid program is
> that setuid/setcap must only be set on executables that have taken
> responsibility for ensuring that they can't create insecure situations
> (for example bubblewrap always sets PR_SET_NO_NEW_PRIVS, unconditionally,
> for this reason).
>
> A large part of why bubblewrap no longer supports being setuid is that
> its maintainers don't want it to have this heavy responsibility.
>
Understandable. I guess my usecase proposed was narrower than thought.
And we probably want to avoid creating risky confused deputy scenarios.
So now I'm leaning towards the LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS path,
dropping the "ON_EXEC" part as Mickaël proposed.
But I'm struggling to see where the value is added over the prctl call.
Sure atomic enforcement with the ruleset is nice, but not a huge value added
on it's own.
Perhaps the setting of this bit with a -1 ruleset_fd could enable auditing
of the (failed or successful) privilege acquisition for the domain via the
fcaps/suid/guid methods w/o setting NNP? (otherwise this would be no
different from a Landlock specific prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
call).
And setting it with a non -1 ruleset_fd would set NNP *and* enable the
same auditing.
That way we are making this a "value-added" flag instead of just a landlock-flavored
prctl call.
This would work well with the LANDLOCK_PERM_CAPABILITY_USE proposal,
which allows us to audit both methods of acquiring new capabilities.
(the clone/unshare path, and the fcaps/setuid/setgid path).
What do you think Mickaël?
Justin
> smcv
^ permalink raw reply
* Re: [GIT PULL] selinux/selinux-pr-20260710
From: pr-tracker-bot @ 2026-07-11 3:07 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, selinux, linux-security-module, linux-kernel
In-Reply-To: <44e0f55f936543053d657f0a86a53bd9@paul-moore.com>
The pull request you sent on Fri, 10 Jul 2026 15:13:45 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20260710
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ccce5f6e7c86f103d76534e2d06d1c903dce551c
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ 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