* [PATCH v3] ima_fs: Avoid creating measurement lists for unsupported hash algos
From: Dmitry Safonov via B4 Relay @ 2026-01-27 14:21 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi
Cc: linux-integrity, linux-security-module, linux-kernel, stable,
Dmitry Safonov, Dmitry Safonov
From: Dmitry Safonov <dima@arista.com>
ima_init_crypto() skips initializing ima_algo_array[i] if the algorithm
from ima_tpm_chip->allocated_banks[i].crypto_id is not supported.
It seems avoid adding the unsupported algorithm to ima_algo_array will
break all the logic that relies on indexing by NR_BANKS(ima_tpm_chip).
On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
> ==================================================================
> BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
> Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
>
> CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
> Call Trace:
> <TASK>
> dump_stack_lvl+0x61/0x90
> print_report+0xc4/0x580
> ? kasan_addr_to_slab+0x26/0x80
> ? create_securityfs_measurement_lists+0x396/0x440
> kasan_report+0xc2/0x100
> ? create_securityfs_measurement_lists+0x396/0x440
> create_securityfs_measurement_lists+0x396/0x440
> ima_fs_init+0xa3/0x300
> ima_init+0x7d/0xd0
> init_ima+0x28/0x100
> do_one_initcall+0xa6/0x3e0
> kernel_init_freeable+0x455/0x740
> kernel_init+0x24/0x1d0
> ret_from_fork+0x38/0x80
> ret_from_fork_asm+0x11/0x20
> </TASK>
>
> The buggy address belongs to the variable:
> hash_algo_name+0xb8/0x420
>
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x107ce18
> flags: 0x8000000000002000(reserved|zone=2)
> raw: 8000000000002000 ffffea0041f38608 ffffea0041f38608 0000000000000000
> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
> ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
> ^
> ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
> ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
> ==================================================================
Seems like the TPM chip supports sha3_256, which isn't yet in
tpm_algorithms:
> tpm tpm0: TPM with unsupported bank algorithm 0x0027
Grepping HASH_ALGO__LAST in security/integrity/ima/ shows that is
the check other logic relies on, so add files under TPM_ALG_<ID>
and print 0 as their hash_digest_size.
This is how it looks on the test machine I have:
> # ls -1 /sys/kernel/security/ima/
> ascii_runtime_measurements
> ascii_runtime_measurements_TPM_ALG_27
> ascii_runtime_measurements_sha1
> ascii_runtime_measurements_sha256
> binary_runtime_measurements
> binary_runtime_measurements_TPM_ALG_27
> binary_runtime_measurements_sha1
> binary_runtime_measurements_sha256
> policy
> runtime_measurements_count
> violations
Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm")
Signed-off-by: Dmitry Safonov <dima@arista.com>
Cc: Enrico Bravi <enrico.bravi@polito.it>
Cc: Silvia Sisinni <silvia.sisinni@polito.it>
Cc: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
---
Changes in v3:
- Now fix the spelling *for real* (sorry, messed it up in v2)
- Link to v2: https://lore.kernel.org/r/20260127-ima-oob-v2-1-f38a18c850cf@arista.com
Changes in v2:
- Instead of skipping unknown algorithms, add files under their TPM_ALG_ID (Roberto Sassu)
- Fix spelling (Roberto Sassu)
- Copy @stable on the fix
- Link to v1: https://lore.kernel.org/r/20260127-ima-oob-v1-1-2d42f3418e57@arista.com
---
security/integrity/ima/ima_fs.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index 012a58959ff0..3b442e3f84d0 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -160,7 +160,10 @@ int ima_measurements_show(struct seq_file *m, void *v)
ima_putc(m, &pcr, sizeof(e->pcr));
/* 2nd: template digest */
- ima_putc(m, e->digests[algo_idx].digest, hash_digest_size[algo]);
+ if (algo == HASH_ALGO__LAST)
+ ima_putc(m, "0", 1);
+ else
+ ima_putc(m, e->digests[algo_idx].digest, hash_digest_size[algo]);
/* 3rd: template name size */
namelen = !ima_canonical_fmt ? strlen(template_name) :
@@ -252,7 +255,10 @@ static int ima_ascii_measurements_show(struct seq_file *m, void *v)
seq_printf(m, "%2d ", e->pcr);
/* 2nd: template hash */
- ima_print_digest(m, e->digests[algo_idx].digest, hash_digest_size[algo]);
+ if (algo == HASH_ALGO__LAST)
+ ima_putc(m, "0", 1);
+ else
+ ima_print_digest(m, e->digests[algo_idx].digest, hash_digest_size[algo]);
/* 3th: template name */
seq_printf(m, " %s", template_name);
@@ -404,16 +410,24 @@ static int __init create_securityfs_measurement_lists(void)
char file_name[NAME_MAX + 1];
struct dentry *dentry;
- sprintf(file_name, "ascii_runtime_measurements_%s",
- hash_algo_name[algo]);
+ if (algo == HASH_ALGO__LAST)
+ sprintf(file_name, "ascii_runtime_measurements_TPM_ALG_%x",
+ ima_tpm_chip->allocated_banks[i].alg_id);
+ else
+ sprintf(file_name, "ascii_runtime_measurements_%s",
+ hash_algo_name[algo]);
dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
ima_dir, (void *)(uintptr_t)i,
&ima_ascii_measurements_ops);
if (IS_ERR(dentry))
return PTR_ERR(dentry);
- sprintf(file_name, "binary_runtime_measurements_%s",
- hash_algo_name[algo]);
+ if (algo == HASH_ALGO__LAST)
+ sprintf(file_name, "binary_runtime_measurements_TPM_ALG_%x",
+ ima_tpm_chip->allocated_banks[i].alg_id);
+ else
+ sprintf(file_name, "binary_runtime_measurements_%s",
+ hash_algo_name[algo]);
dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
ima_dir, (void *)(uintptr_t)i,
&ima_measurements_ops);
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260127-ima-oob-9fa83a634d7b
Best regards,
--
Dmitry Safonov <dima@arista.com>
^ permalink raw reply related
* [PATCH v2] ima_fs: Avoid creating measurement lists for unsupported hash algos
From: Dmitry Safonov via B4 Relay @ 2026-01-27 14:18 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi
Cc: linux-integrity, linux-security-module, linux-kernel, stable,
Dmitry Safonov, Dmitry Safonov
From: Dmitry Safonov <dima@arista.com>
ima_init_crypto() skips initializing ima_algo_array[i] if the alogorithm
from ima_tpm_chip->allocated_banks[i].crypto_id is not supported.
It seems avoid adding the unsupported algorithm to ima_algo_array will
break all the logic that relies on indexing by NR_BANKS(ima_tpm_chip).
On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
> ==================================================================
> BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
> Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
>
> CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
> Call Trace:
> <TASK>
> dump_stack_lvl+0x61/0x90
> print_report+0xc4/0x580
> ? kasan_addr_to_slab+0x26/0x80
> ? create_securityfs_measurement_lists+0x396/0x440
> kasan_report+0xc2/0x100
> ? create_securityfs_measurement_lists+0x396/0x440
> create_securityfs_measurement_lists+0x396/0x440
> ima_fs_init+0xa3/0x300
> ima_init+0x7d/0xd0
> init_ima+0x28/0x100
> do_one_initcall+0xa6/0x3e0
> kernel_init_freeable+0x455/0x740
> kernel_init+0x24/0x1d0
> ret_from_fork+0x38/0x80
> ret_from_fork_asm+0x11/0x20
> </TASK>
>
> The buggy address belongs to the variable:
> hash_algo_name+0xb8/0x420
>
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x107ce18
> flags: 0x8000000000002000(reserved|zone=2)
> raw: 8000000000002000 ffffea0041f38608 ffffea0041f38608 0000000000000000
> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
> ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
> ^
> ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
> ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
> ==================================================================
Seems like the TPM chip supports sha3_256, which isn't yet in
tpm_algorithms:
> tpm tpm0: TPM with unsupported bank algorithm 0x0027
Grepping HASH_ALGO__LAST in security/integrity/ima/ shows that is
the check other logic relies on, so add files under TPM_ALG_<ID>
and print 0 as their hash_digest_size.
This is how it looks on the test machine I have:
> # ls -1 /sys/kernel/security/ima/
> ascii_runtime_measurements
> ascii_runtime_measurements_TPM_ALG_27
> ascii_runtime_measurements_sha1
> ascii_runtime_measurements_sha256
> binary_runtime_measurements
> binary_runtime_measurements_TPM_ALG_27
> binary_runtime_measurements_sha1
> binary_runtime_measurements_sha256
> policy
> runtime_measurements_count
> violations
Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm")
Signed-off-by: Dmitry Safonov <dima@arista.com>
Cc: Enrico Bravi <enrico.bravi@polito.it>
Cc: Silvia Sisinni <silvia.sisinni@polito.it>
Cc: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
---
Changes in v2:
- Instead of skipping unknown algorithms, add files under their TPM_ALG_ID (Roberto Sassu)
- Fix spelling (Roberto Sassu)
- Copy @stable on the fix
- Link to v1: https://lore.kernel.org/r/20260127-ima-oob-v1-1-2d42f3418e57@arista.com
---
security/integrity/ima/ima_fs.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index 012a58959ff0..3b442e3f84d0 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -160,7 +160,10 @@ int ima_measurements_show(struct seq_file *m, void *v)
ima_putc(m, &pcr, sizeof(e->pcr));
/* 2nd: template digest */
- ima_putc(m, e->digests[algo_idx].digest, hash_digest_size[algo]);
+ if (algo == HASH_ALGO__LAST)
+ ima_putc(m, "0", 1);
+ else
+ ima_putc(m, e->digests[algo_idx].digest, hash_digest_size[algo]);
/* 3rd: template name size */
namelen = !ima_canonical_fmt ? strlen(template_name) :
@@ -252,7 +255,10 @@ static int ima_ascii_measurements_show(struct seq_file *m, void *v)
seq_printf(m, "%2d ", e->pcr);
/* 2nd: template hash */
- ima_print_digest(m, e->digests[algo_idx].digest, hash_digest_size[algo]);
+ if (algo == HASH_ALGO__LAST)
+ ima_putc(m, "0", 1);
+ else
+ ima_print_digest(m, e->digests[algo_idx].digest, hash_digest_size[algo]);
/* 3th: template name */
seq_printf(m, " %s", template_name);
@@ -404,16 +410,24 @@ static int __init create_securityfs_measurement_lists(void)
char file_name[NAME_MAX + 1];
struct dentry *dentry;
- sprintf(file_name, "ascii_runtime_measurements_%s",
- hash_algo_name[algo]);
+ if (algo == HASH_ALGO__LAST)
+ sprintf(file_name, "ascii_runtime_measurements_TPM_ALG_%x",
+ ima_tpm_chip->allocated_banks[i].alg_id);
+ else
+ sprintf(file_name, "ascii_runtime_measurements_%s",
+ hash_algo_name[algo]);
dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
ima_dir, (void *)(uintptr_t)i,
&ima_ascii_measurements_ops);
if (IS_ERR(dentry))
return PTR_ERR(dentry);
- sprintf(file_name, "binary_runtime_measurements_%s",
- hash_algo_name[algo]);
+ if (algo == HASH_ALGO__LAST)
+ sprintf(file_name, "binary_runtime_measurements_TPM_ALG_%x",
+ ima_tpm_chip->allocated_banks[i].alg_id);
+ else
+ sprintf(file_name, "binary_runtime_measurements_%s",
+ hash_algo_name[algo]);
dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
ima_dir, (void *)(uintptr_t)i,
&ima_measurements_ops);
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260127-ima-oob-9fa83a634d7b
Best regards,
--
Dmitry Safonov <dima@arista.com>
^ permalink raw reply related
* Re: [PATCH v2 00/13] mm: add bitmap VMA flag helpers and convert all mmap_prepare to use them
From: Yury Norov @ 2026-01-27 13:53 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Jarkko Sakkinen, Dave Hansen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Zi Yan, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Jann Horn, Pedro Falcato, David Howells, Paul Moore,
James Morris, Serge E . Hallyn, Yury Norov, Rasmus Villemoes,
linux-sgx, linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module,
Jason Gunthorpe
In-Reply-To: <cover.1769097829.git.lorenzo.stoakes@oracle.com>
On Thu, Jan 22, 2026 at 04:06:09PM +0000, Lorenzo Stoakes wrote:
> We introduced the bitmap VMA type vma_flags_t in the aptly named commit
> 9ea35a25d51b ("mm: introduce VMA flags bitmap type") in order to permit
> future growth in VMA flags and to prevent the asinine requirement that VMA
> flags be available to 64-bit kernels only if they happened to use a bit
> number about 32-bits.
>
> This is a long-term project as there are very many users of VMA flags
> within the kernel that need to be updated in order to utilise this new
> type.
>
> In order to further this aim, this series adds a number of helper functions
> to enable ordinary interactions with VMA flags - that is testing, setting
> and clearing them.
>
> In order to make working with VMA bit numbers less cumbersome this series
> introduces the mk_vma_flags() helper macro which generates a vma_flags_t
> from a variadic parameter list, e.g.:
>
> vma_flags_t flags = mk_vma_flags(VMA_READ_BIT, VMA_WRITE_BIT,
> VMA_EXEC_BIT);
This should go on the bitmaps level. There's at least one another
possible client for this function - mm_flags_t. Maybe another generic
header bitmap_flags.h?
> It turns out that the compiler optimises this very well to the point that
> this is just as efficient as using VM_xxx pre-computed bitmap values.
It turns out, it's not a compiler - it's people writing code well. :)
Can you please mention the test_bitmap_const_eval() here and also
discuss configurations that break compile-time evaluation, like
KASAN+GCOV?
> This series then introduces the following functions:
>
> bool vma_flags_test_mask(vma_flags_t flags, vma_flags_t to_test);
> bool vma_flags_test_all_mask(vma_flags_t flags, vma_flags_t to_test);
> void vma_flags_set_mask(vma_flags_t *flags, vma_flags_t to_set);
> void vma_flags_clear_mask(vma_flags_t *flags, vma_flags_t to_clear);
>
> Providing means of testing any flag, testing all flags, setting, and clearing a
> specific vma_flags_t mask.
>
> For convenience, helper macros are provided - vma_flags_test(),
> vma_flags_set() and vma_flags_clear(), each of which utilise mk_vma_flags()
> to make these operations easier, as well as an EMPTY_VMA_FLAGS macro to
> make initialisation of an empty vma_flags_t value easier, e.g.:
>
> vma_flags_t flags = EMPTY_VMA_FLAGS;
>
> vma_flags_set(&flags, VMA_READ_BIT, VMA_WRITE_BIT, VMA_EXEC_BIT);
> ...
> if (vma_flags_test(flags, VMA_READ_BIT)) {
> ...
> }
> ...
> if (vma_flags_test_all_mask(flags, VMA_REMAP_FLAGS)) {
> ...
> }
> ...
> vma_flags_clear(&flags, VMA_READ_BIT);
>
> Since callers are often dealing with a vm_area_struct (VMA) or vm_area_desc
> (VMA descriptor as used in .mmap_prepare) object, this series further
> provides helpers for these - firstly vma_set_flags_mask() and vma_set_flags() for a
> VMA:
>
> vma_flags_t flags = EMPTY_VMA_FLAGS:
>
> vma_flags_set(&flags, VMA_READ_BIT, VMA_WRITE_BIT, VMA_EXEC_BIT);
> ...
> vma_set_flags_mask(&vma, flags);
> ...
> vma_set_flags(&vma, VMA_DONTDUMP_BIT);
Having both vma_set_flags() and vma_flags_set() looks confusing...
> Note that these do NOT ensure appropriate locks are taken and assume the
> callers takes care of this.
>
> For VMA descriptors this series adds vma_desc_[test, set,
> clear]_flags_mask() and vma_desc_[test, set, clear]_flags() for a VMA
> descriptor, e.g.:
>
> static int foo_mmap_prepare(struct vm_area_desc *desc)
> {
> ...
> vma_desc_set_flags(desc, VMA_SEQ_READ_BIT);
> vma_desc_clear_flags(desc, VMA_RAND_READ_BIT);
> ...
> if (vma_desc_test_flags(desc, VMA_SHARED_BIT) {
> ...
> }
> ...
> }
>
> With these helpers introduced, this series then updates all mmap_prepare
> users to make use of the vma_flags_t vm_area_desc->vma_flags field rather
> than the legacy vm_flags_t vm_area_desc->vm_flags field.
>
> In order to do so, several other related functions need to be updated, with
> separate patches for larger changes in hugetlbfs, secretmem and shmem
> before finally removing vm_area_desc->vm_flags altogether.
>
> This lays the foundations for future elimination of vm_flags_t and
> associated defines and functionality altogether in the long run, and
> elimination of the use of vm_flags_t in f_op->mmap() hooks in the near term
> as mmap_prepare replaces these.
>
> There is a useful synergy between the VMA flags and mmap_prepare work here
> as with this change in place, converting f_op->mmap() to f_op->mmap_prepare
> naturally also converts use of vm_flags_t to vma_flags_t in all drivers
> which declare mmap handlers.
>
> This accounts for the majority of the users of the legacy vm_flags_*()
> helpers and thus a large number of drivers which need to interact with VMA
> flags in general.
>
> This series also updates the userland VMA tests to account for the change,
> and adds unit tests for these helper functions to assert that they behave
> as expected.
>
> In order to faciliate this change in a sensible way, the series also
> separates out the VMA unit tests into - code that is duplicated from the
> kernel that should be kept in sync, code that is customised for test
> purposes and code that is stubbed out.
>
> We also separate out the VMA userland tests into separate files to make it
> easier to manage and to provide a sensible baseline for adding the userland
> tests for these helpers.
>
>
> REVIEWS NOTE: I rebased this on
> https://lore.kernel.org/linux-mm/cover.1769086312.git.lorenzo.stoakes@oracle.com/
> in order to make life easier with conflict resolutions.
Before I deep into implementation details, can you share more background?
It seems you're implementing an arbitrary-length flags for VMAs, but the
length that you actually set is unconditionally 64. So why just not use
u64 for this?
Even if you expect adding more flags, u128 would double your capacity,
and people will still be able to use language-supported operation on
the bits in flag. Which looks simpler to me...
Thanks,
Yury
^ permalink raw reply
* Re: [PATCH v5 06/36] cleanup: Basic compatibility with context analysis
From: Lorenzo Stoakes @ 2026-01-27 10:21 UTC (permalink / raw)
To: Marco Elver
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Bart Van Assche,
Christoph Hellwig, Dmitry Vyukov, Eric Dumazet,
Frederic Weisbecker, Greg Kroah-Hartman, Herbert Xu, Ian Rogers,
Jann Horn, Joel Fernandes, Johannes Berg, Jonathan Corbet,
Josh Triplett, Justin Stitt, Kees Cook, Kentaro Takeda,
Lukas Bulwahn, Mark Rutland, Mathieu Desnoyers, Miguel Ojeda,
Nathan Chancellor, Neeraj Upadhyay, Nick Desaulniers,
Steven Rostedt, Tetsuo Handa, Thomas Gleixner, Thomas Graf,
Uladzislau Rezki, Waiman Long, kasan-dev, linux-crypto, linux-doc,
linux-kbuild, linux-kernel, linux-mm, linux-security-module,
linux-sparse, linux-wireless, llvm, rcu, Sidhartha Kumar
In-Reply-To: <CANpmjNNHmOzaCSc9hQJNuzNVHXA=LRgXB4Q69FNk6wBuuJGdAg@mail.gmail.com>
On Tue, Jan 27, 2026 at 11:17:24AM +0100, Marco Elver wrote:
> On Tue, 27 Jan 2026 at 11:14, Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > +cc Sid for awareness
> >
> > Hi,
> >
> > This patch breaks the radix tree and VMA userland tests. The next bots didn't
> > catch it but it seems now they're building the userland VMA tests
> > (e.g. https://lore.kernel.all/202601271308.b8d3fcb6-lkp@intel.com/) but maybe
> > not caught up to the issue this one caused (fails build in tools/testing/vma and
> > tools/testing/radix-tree).
> >
> > Anyway it's a really easy fix, just need to stub out __no_context_analysis in
> > the tools/include copy of compiler_types.h, fix-patch provided below.
> >
> > To avoid bisection hazard it'd be nice if it could be folded into this series
> > before this patch, but if we're too late in the cycle for that I can submit a
> > fix separately.
>
> Thanks, I saw. I have a more complete fix I'm about to send.
Great, thanks!
^ permalink raw reply
* Re: [PATCH v5 06/36] cleanup: Basic compatibility with context analysis
From: Marco Elver @ 2026-01-27 10:17 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Bart Van Assche,
Christoph Hellwig, Dmitry Vyukov, Eric Dumazet,
Frederic Weisbecker, Greg Kroah-Hartman, Herbert Xu, Ian Rogers,
Jann Horn, Joel Fernandes, Johannes Berg, Jonathan Corbet,
Josh Triplett, Justin Stitt, Kees Cook, Kentaro Takeda,
Lukas Bulwahn, Mark Rutland, Mathieu Desnoyers, Miguel Ojeda,
Nathan Chancellor, Neeraj Upadhyay, Nick Desaulniers,
Steven Rostedt, Tetsuo Handa, Thomas Gleixner, Thomas Graf,
Uladzislau Rezki, Waiman Long, kasan-dev, linux-crypto, linux-doc,
linux-kbuild, linux-kernel, linux-mm, linux-security-module,
linux-sparse, linux-wireless, llvm, rcu, Sidhartha Kumar
In-Reply-To: <0c2d9b69-c052-4075-8a4b-023d277b8509@lucifer.local>
On Tue, 27 Jan 2026 at 11:14, Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> +cc Sid for awareness
>
> Hi,
>
> This patch breaks the radix tree and VMA userland tests. The next bots didn't
> catch it but it seems now they're building the userland VMA tests
> (e.g. https://lore.kernel.all/202601271308.b8d3fcb6-lkp@intel.com/) but maybe
> not caught up to the issue this one caused (fails build in tools/testing/vma and
> tools/testing/radix-tree).
>
> Anyway it's a really easy fix, just need to stub out __no_context_analysis in
> the tools/include copy of compiler_types.h, fix-patch provided below.
>
> To avoid bisection hazard it'd be nice if it could be folded into this series
> before this patch, but if we're too late in the cycle for that I can submit a
> fix separately.
Thanks, I saw. I have a more complete fix I'm about to send.
^ permalink raw reply
* Re: [PATCH v5 06/36] cleanup: Basic compatibility with context analysis
From: Lorenzo Stoakes @ 2026-01-27 10:14 UTC (permalink / raw)
To: Marco Elver
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Bart Van Assche,
Christoph Hellwig, Dmitry Vyukov, Eric Dumazet,
Frederic Weisbecker, Greg Kroah-Hartman, Herbert Xu, Ian Rogers,
Jann Horn, Joel Fernandes, Johannes Berg, Jonathan Corbet,
Josh Triplett, Justin Stitt, Kees Cook, Kentaro Takeda,
Lukas Bulwahn, Mark Rutland, Mathieu Desnoyers, Miguel Ojeda,
Nathan Chancellor, Neeraj Upadhyay, Nick Desaulniers,
Steven Rostedt, Tetsuo Handa, Thomas Gleixner, Thomas Graf,
Uladzislau Rezki, Waiman Long, kasan-dev, linux-crypto, linux-doc,
linux-kbuild, linux-kernel, linux-mm, linux-security-module,
linux-sparse, linux-wireless, llvm, rcu, Sidhartha Kumar
In-Reply-To: <20251219154418.3592607-7-elver@google.com>
+cc Sid for awareness
Hi,
This patch breaks the radix tree and VMA userland tests. The next bots didn't
catch it but it seems now they're building the userland VMA tests
(e.g. https://lore.kernel.all/202601271308.b8d3fcb6-lkp@intel.com/) but maybe
not caught up to the issue this one caused (fails build in tools/testing/vma and
tools/testing/radix-tree).
Anyway it's a really easy fix, just need to stub out __no_context_analysis in
the tools/include copy of compiler_types.h, fix-patch provided below.
To avoid bisection hazard it'd be nice if it could be folded into this series
before this patch, but if we're too late in the cycle for that I can submit a
fix separately.
Thanks, Lorenzo
----8<----
From cc2390dbefed156757f001e8c3a500a6f8aa1244 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Tue, 27 Jan 2026 10:10:55 +0000
Subject: [PATCH] fix
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
tools/include/linux/compiler_types.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/include/linux/compiler_types.h b/tools/include/linux/compiler_types.h
index 949b2cdd3412..ca60d491d4e8 100644
--- a/tools/include/linux/compiler_types.h
+++ b/tools/include/linux/compiler_types.h
@@ -60,4 +60,6 @@
__scalar_type_to_expr_cases(long long), \
default: (x)))
+#define __no_context_analysis
+
#endif /* __LINUX_COMPILER_TYPES_H */
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] ima_fs: Avoid creating measurement lists for unsupported hash algos
From: Dmitry Safonov @ 2026-01-27 10:12 UTC (permalink / raw)
To: Roberto Sassu
Cc: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi, linux-integrity, linux-security-module,
linux-kernel, Dmitry Safonov
In-Reply-To: <caebe20b5f30cb76ba8021443ba50ad06a2ef570.camel@huaweicloud.com>
On Tue, Jan 27, 2026 at 10:02 AM Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
[..]
> > I'm not quite sure what you mean. `algo` here is HASH_ALGO__LAST as
> > you see by the check added. As it's initialized by
> > ima_tpm_chip->allocated_banks[i].crypto_id, I presume it's
> > HASH_ALGO__LAST there as well (didn't check this assumption though).
> > Do you mean to print hex value of HASH_ALGO__LAST?
>
> Even if you don't have the crypto ID because the TPM ID is not mapped,
> you can still use the TPM ID (ima_tpm_chip->allocated_banks[i].alg_id).
>
> I wanted to have a file name that includes the TPM ID.
I see, thanks, I'll try this.
Thanks,
Dmitry
^ permalink raw reply
* Re: [PATCH v2 12/13] tools/testing/vma: separate out vma_internal.h into logical headers
From: Lorenzo Stoakes @ 2026-01-27 10:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Jarkko Sakkinen, Dave Hansen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, x86, H . Peter Anvin, Arnd Bergmann,
Greg Kroah-Hartman, Dan Williams, Vishal Verma, Dave Jiang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Christian Koenig, Huang Rui, Matthew Auld,
Matthew Brost, Alexander Viro, Christian Brauner, Jan Kara,
Benjamin LaHaise, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Theodore Ts'o,
Andreas Dilger, Muchun Song, Oscar Salvador, David Hildenbrand,
Konstantin Komarov, Mike Marshall, Martin Brandenburg, Tony Luck,
Reinette Chatre, Dave Martin, James Morse, Babu Moger,
Carlos Maiolino, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
Matthew Wilcox, Liam R . Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Hugh Dickins, Baolin Wang,
Zi Yan, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Jann Horn, Pedro Falcato, David Howells, Paul Moore,
James Morris, Serge E . Hallyn, Yury Norov, Rasmus Villemoes,
linux-sgx, linux-kernel, nvdimm, linux-cxl, dri-devel, intel-gfx,
linux-fsdevel, linux-aio, linux-erofs, linux-ext4, linux-mm,
ntfs3, devel, linux-xfs, keyrings, linux-security-module,
Jason Gunthorpe
In-Reply-To: <dd57baf5b5986cb96a167150ac712cbe804b63ee.1769097829.git.lorenzo.stoakes@oracle.com>
Hi Andrew,
Could you apply the attached fix-patch to avoid a duplicate struct define as
reported by https://lore.kernel.org/all/202601271308.b8d3fcb6-lkp@intel.com/ ?
Thanks, Lorenzo
----8<----
From d19e621020697b25d70f13ffeb2b0eb46682a60d Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Tue, 27 Jan 2026 10:02:00 +0000
Subject: [PATCH] fix
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
tools/testing/vma/include/dup.h | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/tools/testing/vma/include/dup.h b/tools/testing/vma/include/dup.h
index ed8708afb7af..0accfc296615 100644
--- a/tools/testing/vma/include/dup.h
+++ b/tools/testing/vma/include/dup.h
@@ -1327,15 +1327,3 @@ static inline void vma_set_file(struct vm_area_struct *vma, struct file *file)
swap(vma->vm_file, file);
fput(file);
}
-
-struct unmap_desc {
- struct ma_state *mas; /* the maple state point to the first vma */
- struct vm_area_struct *first; /* The first vma */
- unsigned long pg_start; /* The first pagetable address to free (floor) */
- unsigned long pg_end; /* The last pagetable address to free (ceiling) */
- unsigned long vma_start; /* The min vma address */
- unsigned long vma_end; /* The max vma address */
- unsigned long tree_end; /* Maximum for the vma tree search */
- unsigned long tree_reset; /* Where to reset the vma tree walk */
- bool mm_wr_locked; /* If the mmap write lock is held */
-};
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] ima_fs: Avoid creating measurement lists for unsupported hash algos
From: Roberto Sassu @ 2026-01-27 10:02 UTC (permalink / raw)
To: Dmitry Safonov
Cc: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi, linux-integrity, linux-security-module,
linux-kernel, Dmitry Safonov
In-Reply-To: <CAGrbwDRgQShh==Vb_8QWoByKV-HXAwV_CGyAoAzjRrHU9c2KbQ@mail.gmail.com>
On Tue, 2026-01-27 at 09:55 +0000, Dmitry Safonov wrote:
> On Tue, Jan 27, 2026 at 9:15 AM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
> >
> > On Tue, 2026-01-27 at 03:05 +0000, Dmitry Safonov via B4 Relay wrote:
> > > From: Dmitry Safonov <dima@arista.com>
> > >
> > > ima_init_crypto() skips initializing ima_algo_array[i] if the alogorithm
> >
> > Algorithm.
>
> Thanks.
>
> [..]
> > > --- a/security/integrity/ima/ima_fs.c
> > > +++ b/security/integrity/ima/ima_fs.c
> > > @@ -404,6 +404,9 @@ static int __init create_securityfs_measurement_lists(void)
> > > char file_name[NAME_MAX + 1];
> > > struct dentry *dentry;
> > >
> > > + if (algo == HASH_ALGO__LAST)
> > > + continue;
> > > +
> > > sprintf(file_name, "ascii_runtime_measurements_%s",
> > > hash_algo_name[algo]);
> >
> > Thanks, but I think we can also print the unsupported digests, since
> > they are there. Since we don't have the algorithm name, we can make
> > ours like tpm_<algo hex>.
>
> I'm not quite sure what you mean. `algo` here is HASH_ALGO__LAST as
> you see by the check added. As it's initialized by
> ima_tpm_chip->allocated_banks[i].crypto_id, I presume it's
> HASH_ALGO__LAST there as well (didn't check this assumption though).
> Do you mean to print hex value of HASH_ALGO__LAST?
Even if you don't have the crypto ID because the TPM ID is not mapped,
you can still use the TPM ID (ima_tpm_chip->allocated_banks[i].alg_id).
I wanted to have a file name that includes the TPM ID.
Roberto
> > Once this is fixed, you can try to make SHA3_256 supported. Add the
> > TPM_ALG_SHA3_256 definition in tpm.h and the mapping in tpm2-cmd.c
> > (array tpm2_hash_map).
>
> Yeah, I thought of doing this, asked the related folks and they said
> it might be worth if it's a simple/trivial patch. Will try if time
> permits, somewhat busy with bug fixes at this moment. This one is just
> a fix for read out-of-bounds for -stable (and I managed to forget to
> Cc them! hehe).
>
> Going to send v2 with the typo fix and -stable Cc'ed if that sounds good to you.
>
> >
> > Thanks
> >
> > Roberto
> [..]
>
> Thanks,
> Dmitry
^ permalink raw reply
* Re: [PATCH] ima_fs: Avoid creating measurement lists for unsupported hash algos
From: Dmitry Safonov @ 2026-01-27 9:55 UTC (permalink / raw)
To: Roberto Sassu
Cc: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi, linux-integrity, linux-security-module,
linux-kernel, Dmitry Safonov
In-Reply-To: <b873ba2c8057aa749aa0d058002a30776d0a5248.camel@huaweicloud.com>
On Tue, Jan 27, 2026 at 9:15 AM Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
>
> On Tue, 2026-01-27 at 03:05 +0000, Dmitry Safonov via B4 Relay wrote:
> > From: Dmitry Safonov <dima@arista.com>
> >
> > ima_init_crypto() skips initializing ima_algo_array[i] if the alogorithm
>
> Algorithm.
Thanks.
[..]
> > --- a/security/integrity/ima/ima_fs.c
> > +++ b/security/integrity/ima/ima_fs.c
> > @@ -404,6 +404,9 @@ static int __init create_securityfs_measurement_lists(void)
> > char file_name[NAME_MAX + 1];
> > struct dentry *dentry;
> >
> > + if (algo == HASH_ALGO__LAST)
> > + continue;
> > +
> > sprintf(file_name, "ascii_runtime_measurements_%s",
> > hash_algo_name[algo]);
>
> Thanks, but I think we can also print the unsupported digests, since
> they are there. Since we don't have the algorithm name, we can make
> ours like tpm_<algo hex>.
I'm not quite sure what you mean. `algo` here is HASH_ALGO__LAST as
you see by the check added. As it's initialized by
ima_tpm_chip->allocated_banks[i].crypto_id, I presume it's
HASH_ALGO__LAST there as well (didn't check this assumption though).
Do you mean to print hex value of HASH_ALGO__LAST?
> Once this is fixed, you can try to make SHA3_256 supported. Add the
> TPM_ALG_SHA3_256 definition in tpm.h and the mapping in tpm2-cmd.c
> (array tpm2_hash_map).
Yeah, I thought of doing this, asked the related folks and they said
it might be worth if it's a simple/trivial patch. Will try if time
permits, somewhat busy with bug fixes at this moment. This one is just
a fix for read out-of-bounds for -stable (and I managed to forget to
Cc them! hehe).
Going to send v2 with the typo fix and -stable Cc'ed if that sounds good to you.
>
> Thanks
>
> Roberto
[..]
Thanks,
Dmitry
^ permalink raw reply
* Re: [PATCH] ima_fs: Avoid creating measurement lists for unsupported hash algos
From: Roberto Sassu @ 2026-01-27 9:14 UTC (permalink / raw)
To: dima, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi
Cc: linux-integrity, linux-security-module, linux-kernel,
Dmitry Safonov
In-Reply-To: <20260127-ima-oob-v1-1-2d42f3418e57@arista.com>
On Tue, 2026-01-27 at 03:05 +0000, Dmitry Safonov via B4 Relay wrote:
> From: Dmitry Safonov <dima@arista.com>
>
> ima_init_crypto() skips initializing ima_algo_array[i] if the alogorithm
Algorithm.
> from ima_tpm_chip->allocated_banks[i].crypto_id is not supported.
> It seems avoid adding the unsupported algorithm to ima_algo_array will
> break all the logic that relies on indexing by NR_BANKS(ima_tpm_chip).
>
> Grepping HASH_ALGO__LAST in security/integrity/ima/ shows that is
> the check other logic relies on, so make
> create_securityfs_measurement_lists() ignore unknown algorithms.
>
> On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
>
> > ==================================================================
> > BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
> > Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
> >
> > CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
> > Call Trace:
> > <TASK>
> > dump_stack_lvl+0x61/0x90
> > print_report+0xc4/0x580
> > ? kasan_addr_to_slab+0x26/0x80
> > ? create_securityfs_measurement_lists+0x396/0x440
> > kasan_report+0xc2/0x100
> > ? create_securityfs_measurement_lists+0x396/0x440
> > create_securityfs_measurement_lists+0x396/0x440
> > ima_fs_init+0xa3/0x300
> > ima_init+0x7d/0xd0
> > init_ima+0x28/0x100
> > do_one_initcall+0xa6/0x3e0
> > kernel_init_freeable+0x455/0x740
> > kernel_init+0x24/0x1d0
> > ret_from_fork+0x38/0x80
> > ret_from_fork_asm+0x11/0x20
> > </TASK>
> >
> > The buggy address belongs to the variable:
> > hash_algo_name+0xb8/0x420
> >
> > The buggy address belongs to the physical page:
> > page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x107ce18
> > flags: 0x8000000000002000(reserved|zone=2)
> > raw: 8000000000002000 ffffea0041f38608 ffffea0041f38608 0000000000000000
> > raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
> > ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
> > ^
> > ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
> > ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
> > ==================================================================
>
> Seems like the TPM chip supports sha3_256, which isn't yet in
> tpm_algorithms:
> > tpm tpm0: TPM with unsupported bank algorithm 0x0027
>
> Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm")
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> Cc: Enrico Bravi <enrico.bravi@polito.it>
> Cc: Silvia Sisinni <silvia.sisinni@polito.it>
> Cc: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: Mimi Zohar <zohar@linux.ibm.com>
> ---
> security/integrity/ima/ima_fs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
> index 012a58959ff0..e9283229acea 100644
> --- a/security/integrity/ima/ima_fs.c
> +++ b/security/integrity/ima/ima_fs.c
> @@ -404,6 +404,9 @@ static int __init create_securityfs_measurement_lists(void)
> char file_name[NAME_MAX + 1];
> struct dentry *dentry;
>
> + if (algo == HASH_ALGO__LAST)
> + continue;
> +
> sprintf(file_name, "ascii_runtime_measurements_%s",
> hash_algo_name[algo]);
Thanks, but I think we can also print the unsupported digests, since
they are there. Since we don't have the algorithm name, we can make
ours like tpm_<algo hex>.
Once this is fixed, you can try to make SHA3_256 supported. Add the
TPM_ALG_SHA3_256 definition in tpm.h and the mapping in tpm2-cmd.c
(array tpm2_hash_map).
Thanks
Roberto
> dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
>
> ---
> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
> change-id: 20260127-ima-oob-9fa83a634d7b
>
> Best regards,
^ permalink raw reply
* Re: [PATCH] ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit()
From: Ondrej Mosnacek @ 2026-01-27 8:05 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Paul Moore, Andrew Morton, Eric W . Biederman, linux-kernel,
linux-security-module, selinux
In-Reply-To: <aXgZI1td0Hremulj@mail.hallyn.com>
On Tue, Jan 27, 2026 at 2:55 AM Serge E. Hallyn <serge@hallyn.com> wrote:
>
> On Mon, Jan 26, 2026 at 05:52:03PM -0500, Paul Moore wrote:
> > On Thu, Jan 22, 2026 at 9:25 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > >
> > > The user.* sysctls implement the ctl_table_root::permissions hook and
> > > they override the file access mode based on the CAP_SYS_RESOURCE
> > > capability (at most rwx if capable, at most r-- if not). The capability
> > > is being checked unconditionally, so if an LSM denies the capability, an
> > > audit record may be logged even when access is in fact granted.
> > >
> > > Given the logic in the set_permissions() function in kernel/ucount.c and
> > > the unfortunate way the permission checking is implemented, it doesn't
> > > seem viable to avoid false positive denials by deferring the capability
> > > check. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c)
> > > - switch from ns_capable() to ns_capable_noaudit(), so that the check
> > > never logs an audit record.
> > >
> > > Fixes: dbec28460a89 ("userns: Add per user namespace sysctls.")
> > > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> > > ---
> > > kernel/ucount.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Reviewed-by: Paul Moore <paul@paul-moore.com>
>
> Acked-by: Serge Hallyn <serge@hallyn.com>
>
> Looks good to me. What tree should this go through? Network?
Andrew has already applied the two patches I posted into his
mm-nonmm-unstable branch, so I assume they are set to go through his
tree.
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/log/?h=mm-nonmm-unstable
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
^ permalink raw reply
* Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()
From: Tetsuo Handa @ 2026-01-27 3:51 UTC (permalink / raw)
To: Paul Moore, SELinux, linux-security-module
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Network Development
In-Reply-To: <CAHC9VhQikhv+qCyQdnJguvy-qTkGXB+NU7=QZjw5d+WfyVxZhw@mail.gmail.com>
On 2026/01/27 7:33, Paul Moore wrote:
> On Fri, Jan 23, 2026 at 5:13 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>
>> Since xfrm_dev_{state,policy}_flush() are called from only NETDEV_DOWN and
>> NETDEV_UNREGISTER events, making xfrm_dev_{state,policy}_flush() no-op by
>> returning an error value from xfrm_dev_{state,policy}_flush_secctx_check()
>> is pointless. Especially, if xfrm_dev_{state,policy}_flush_secctx_check()
>> returned an error value upon NETDEV_UNREGISTER event, the system will hung
>> up with
>>
>> unregister_netdevice: waiting for $dev to become free. Usage count = $count
>>
>> message because the reference to $dev acquired by
>> xfrm_dev_{state,policy}_add() cannot be released.
>>
>> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>> ---
>> net/xfrm/xfrm_policy.c | 35 -----------------------------------
>> net/xfrm/xfrm_state.c | 33 ---------------------------------
>> 2 files changed, 68 deletions(-)
>
> I didn't make it very far into reviewing this patch, because it looks
> like xfrm_dev_state_flush() is called by the bonding driver's
> notification handler, and I don't see that reflected in this patch?
xfrm_dev_{state,policy}_flush() are called from only the bonding driver's NETDEV_UNREGISTER
event notification handler and the xfrm module's NETDEV_DOWN event / NETDEV_UNREGISTER event
notification handler ( https://elixir.bootlin.com/linux/v6.19-rc5/A/ident/xfrm_dev_state_flush ).
What this patch kills is not xfrm_dev_{state,policy}_flush() but
xfrm_dev_{state,policy}_flush_secctx_check(). No need to touch the bonding driver.
LSM hook for checking whether to allow deleting a file in tmpfs which is still mounted
makes sense, LSM hook for checking whether to allow starting unmount of tmpfs makes sense,
but LSM hook for checking whether to allow releasing memory in tmpfs while unmount operation
is already in progress causes nothing but a resource leak / denial-of-service kernel bug.
What xfrm_dev_{state,policy}_flush_secctx_check() are causing is something like
"LSM policy is refusing release of memory used by a file in tmpfs which is already under
unmount operation".
xfrm_dev_{state,policy}_flush_secctx_check() are too late to make LSM policy decision.
A must-not-fail operation has already started before LSM hooks are called.
^ permalink raw reply
* [PATCH] ima_fs: Avoid creating measurement lists for unsupported hash algos
From: Dmitry Safonov via B4 Relay @ 2026-01-27 3:05 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi
Cc: linux-integrity, linux-security-module, linux-kernel,
Dmitry Safonov, Dmitry Safonov
From: Dmitry Safonov <dima@arista.com>
ima_init_crypto() skips initializing ima_algo_array[i] if the alogorithm
from ima_tpm_chip->allocated_banks[i].crypto_id is not supported.
It seems avoid adding the unsupported algorithm to ima_algo_array will
break all the logic that relies on indexing by NR_BANKS(ima_tpm_chip).
Grepping HASH_ALGO__LAST in security/integrity/ima/ shows that is
the check other logic relies on, so make
create_securityfs_measurement_lists() ignore unknown algorithms.
On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
> ==================================================================
> BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
> Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
>
> CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
> Call Trace:
> <TASK>
> dump_stack_lvl+0x61/0x90
> print_report+0xc4/0x580
> ? kasan_addr_to_slab+0x26/0x80
> ? create_securityfs_measurement_lists+0x396/0x440
> kasan_report+0xc2/0x100
> ? create_securityfs_measurement_lists+0x396/0x440
> create_securityfs_measurement_lists+0x396/0x440
> ima_fs_init+0xa3/0x300
> ima_init+0x7d/0xd0
> init_ima+0x28/0x100
> do_one_initcall+0xa6/0x3e0
> kernel_init_freeable+0x455/0x740
> kernel_init+0x24/0x1d0
> ret_from_fork+0x38/0x80
> ret_from_fork_asm+0x11/0x20
> </TASK>
>
> The buggy address belongs to the variable:
> hash_algo_name+0xb8/0x420
>
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x107ce18
> flags: 0x8000000000002000(reserved|zone=2)
> raw: 8000000000002000 ffffea0041f38608 ffffea0041f38608 0000000000000000
> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
> ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
> ^
> ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
> ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
> ==================================================================
Seems like the TPM chip supports sha3_256, which isn't yet in
tpm_algorithms:
> tpm tpm0: TPM with unsupported bank algorithm 0x0027
Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm")
Signed-off-by: Dmitry Safonov <dima@arista.com>
Cc: Enrico Bravi <enrico.bravi@polito.it>
Cc: Silvia Sisinni <silvia.sisinni@polito.it>
Cc: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
---
security/integrity/ima/ima_fs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index 012a58959ff0..e9283229acea 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -404,6 +404,9 @@ static int __init create_securityfs_measurement_lists(void)
char file_name[NAME_MAX + 1];
struct dentry *dentry;
+ if (algo == HASH_ALGO__LAST)
+ continue;
+
sprintf(file_name, "ascii_runtime_measurements_%s",
hash_algo_name[algo]);
dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260127-ima-oob-9fa83a634d7b
Best regards,
--
Dmitry Safonov <dima@arista.com>
^ permalink raw reply related
* Re: [PATCH] ipc: don't audit capability check in ipc_permissions()
From: Serge E. Hallyn @ 2026-01-27 2:01 UTC (permalink / raw)
To: Paul Moore
Cc: Ondrej Mosnacek, Serge Hallyn, Andrew Morton, Eric W . Biederman,
Alexey Gladkov, linux-kernel, linux-security-module, selinux
In-Reply-To: <CAHC9VhQYLJVweDgBkRo=0_kS1TAUQH_YfT+woSfBW0SjUO4nqg@mail.gmail.com>
On Mon, Jan 26, 2026 at 05:50:12PM -0500, Paul Moore wrote:
> On Thu, Jan 22, 2026 at 9:56 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > The IPC sysctls implement the ctl_table_root::permissions hook and
> > they override the file access mode based on the CAP_CHECKPOINT_RESTORE
> > capability, which is being checked regardless of whether any access is
> > actually denied or not, so if an LSM denies the capability, an audit
> > record may be logged even when access is in fact granted.
> >
> > It wouldn't be viable to restructure the sysctl permission logic to only
> > check the capability when the access would be actually denied if it's
> > not granted. Thus, do the same as in net_ctl_permissions()
> > (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(),
> > so that the check never emits an audit record.
> >
> > Fixes: 0889f44e2810 ("ipc: Check permissions for checkpoint_restart sysctls at open time")
> > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> > ---
> > include/linux/capability.h | 6 ++++++
> > ipc/ipc_sysctl.c | 2 +-
> > 2 files changed, 7 insertions(+), 1 deletion(-)
>
> This change seems reasonable to me, but I would make sure Serge has a
> chance to review/ACK this patch as it has a capability impact.
Acked-by: Serge Hallyn <serge@hallyn.com>
Thanks - looks good to me.
^ permalink raw reply
* Re: [PATCH] ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit()
From: Serge E. Hallyn @ 2026-01-27 1:47 UTC (permalink / raw)
To: Paul Moore
Cc: Ondrej Mosnacek, Andrew Morton, Eric W . Biederman, linux-kernel,
linux-security-module, selinux
In-Reply-To: <CAHC9VhSgbHx4NcMVjMMk0D332b0DTEQi6dD_wO1fvQne-JVisw@mail.gmail.com>
On Mon, Jan 26, 2026 at 05:52:03PM -0500, Paul Moore wrote:
> On Thu, Jan 22, 2026 at 9:25 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > The user.* sysctls implement the ctl_table_root::permissions hook and
> > they override the file access mode based on the CAP_SYS_RESOURCE
> > capability (at most rwx if capable, at most r-- if not). The capability
> > is being checked unconditionally, so if an LSM denies the capability, an
> > audit record may be logged even when access is in fact granted.
> >
> > Given the logic in the set_permissions() function in kernel/ucount.c and
> > the unfortunate way the permission checking is implemented, it doesn't
> > seem viable to avoid false positive denials by deferring the capability
> > check. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c)
> > - switch from ns_capable() to ns_capable_noaudit(), so that the check
> > never logs an audit record.
> >
> > Fixes: dbec28460a89 ("userns: Add per user namespace sysctls.")
> > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> > ---
> > kernel/ucount.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Paul Moore <paul@paul-moore.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
Looks good to me. What tree should this go through? Network?
^ permalink raw reply
* Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
From: Marco Elver @ 2026-01-26 23:46 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Bart Van Assche, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <20260126213556.GQ171111@noisy.programming.kicks-ass.net>
On Mon, 26 Jan 2026 at 22:36, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Jan 26, 2026 at 10:54:56AM -0800, Bart Van Assche wrote:
>
> > Has it ever been considered to add support in the clang compiler for a
> > variant of __must_hold() that expresses that one of two capabilities
> > must be held by the caller? I think that would remove the need to
> > annotate SRCU update-side code with __acquire_shared(ssp) and
> > __release_shared(ssp).
>
> Right, I think I've asked for logical operators like that. Although I
> think it was in the __guarded_by() clause rather than the __must_hold().
> Both || and && would be nice to have ;-)
Some attributes take multiple arguments (__must_hold does), though
__guarded_by doesn't. Yet, && can still be had with adding it multiple
times e.g. '__guarded_by(pi_lock) __guarded_by(rq->__lock)'.
Only thing that doesn't exist is ||. I think the syntax you ask for
won't fly, but I can add it to the backlog to investigate an _any
variant of these attributes. Don't hold your breath though, given the
time it takes to land all that in a released Clang version.
> Specifically, I think I asked for something like:
>
> cpumask_t cpus_allowed __guarded_by(pi_lock && rq->__lock)
> __guarded_shared_by(pi_lock || rq->__lock);
>
>
> I think Marco's suggestion was to use 'fake' locks to mimic those
> semantics.
^ permalink raw reply
* Re: [PATCH] ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit()
From: Paul Moore @ 2026-01-26 22:52 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: Andrew Morton, Eric W . Biederman, linux-kernel,
linux-security-module, selinux
In-Reply-To: <20260122140745.239428-1-omosnace@redhat.com>
On Thu, Jan 22, 2026 at 9:25 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> The user.* sysctls implement the ctl_table_root::permissions hook and
> they override the file access mode based on the CAP_SYS_RESOURCE
> capability (at most rwx if capable, at most r-- if not). The capability
> is being checked unconditionally, so if an LSM denies the capability, an
> audit record may be logged even when access is in fact granted.
>
> Given the logic in the set_permissions() function in kernel/ucount.c and
> the unfortunate way the permission checking is implemented, it doesn't
> seem viable to avoid false positive denials by deferring the capability
> check. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c)
> - switch from ns_capable() to ns_capable_noaudit(), so that the check
> never logs an audit record.
>
> Fixes: dbec28460a89 ("userns: Add per user namespace sysctls.")
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> ---
> kernel/ucount.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Paul Moore <paul@paul-moore.com>
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] ipc: don't audit capability check in ipc_permissions()
From: Paul Moore @ 2026-01-26 22:50 UTC (permalink / raw)
To: Ondrej Mosnacek, Serge Hallyn
Cc: Andrew Morton, Eric W . Biederman, Alexey Gladkov, linux-kernel,
linux-security-module, selinux
In-Reply-To: <20260122141303.241133-1-omosnace@redhat.com>
On Thu, Jan 22, 2026 at 9:56 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> The IPC sysctls implement the ctl_table_root::permissions hook and
> they override the file access mode based on the CAP_CHECKPOINT_RESTORE
> capability, which is being checked regardless of whether any access is
> actually denied or not, so if an LSM denies the capability, an audit
> record may be logged even when access is in fact granted.
>
> It wouldn't be viable to restructure the sysctl permission logic to only
> check the capability when the access would be actually denied if it's
> not granted. Thus, do the same as in net_ctl_permissions()
> (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(),
> so that the check never emits an audit record.
>
> Fixes: 0889f44e2810 ("ipc: Check permissions for checkpoint_restart sysctls at open time")
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> ---
> include/linux/capability.h | 6 ++++++
> ipc/ipc_sysctl.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
This change seems reasonable to me, but I would make sure Serge has a
chance to review/ACK this patch as it has a capability impact.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] xfrm: force flush upon NETDEV_UNREGISTER event
From: Paul Moore @ 2026-01-26 22:41 UTC (permalink / raw)
To: Steffen Klassert
Cc: Tetsuo Handa, Aviad Yehezkel, Aviv Heller, Boris Pismenny,
David S. Miller, Florian Westphal, Guy Shapiro, Ilan Tayari,
Kristian Evensen, Leon Romanovsky, Leon Romanovsky, Raed Salem,
Raed Salem, Saeed Mahameed, Yossi Kuperman, Network Development,
linux-security-module
In-Reply-To: <aXIGxmCB2QU86-iA@secunet.com>
On Thu, Jan 22, 2026 at 7:00 AM Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> On Thu, Jan 22, 2026 at 05:24:22PM +0900, Tetsuo Handa wrote:
...
> > Therefore, I wonder what are security_xfrm_state_delete() and security_xfrm_policy_delete()
> > for. Can I kill xfrm_dev_state_flush_secctx_check() and xfrm_dev_policy_flush_secctx_check() ?
>
> This might violate a LSM policy then.
Exactly. SELinux is currently the only LSM that enforces any access
controls on the XFRM/IPsec code, but it does use both of these LSM
hooks to authorize deletion of SPD/SA objects.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] xfrm: kill xfrm_dev_{state,policy}_flush_secctx_check()
From: Paul Moore @ 2026-01-26 22:33 UTC (permalink / raw)
To: Tetsuo Handa
Cc: linux-security-module, SELinux, Steffen Klassert, Herbert Xu,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Network Development
In-Reply-To: <2ec9c137-79a5-4562-8587-43dd2633f116@I-love.SAKURA.ne.jp>
On Fri, Jan 23, 2026 at 5:13 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> Since xfrm_dev_{state,policy}_flush() are called from only NETDEV_DOWN and
> NETDEV_UNREGISTER events, making xfrm_dev_{state,policy}_flush() no-op by
> returning an error value from xfrm_dev_{state,policy}_flush_secctx_check()
> is pointless. Especially, if xfrm_dev_{state,policy}_flush_secctx_check()
> returned an error value upon NETDEV_UNREGISTER event, the system will hung
> up with
>
> unregister_netdevice: waiting for $dev to become free. Usage count = $count
>
> message because the reference to $dev acquired by
> xfrm_dev_{state,policy}_add() cannot be released.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> net/xfrm/xfrm_policy.c | 35 -----------------------------------
> net/xfrm/xfrm_state.c | 33 ---------------------------------
> 2 files changed, 68 deletions(-)
I didn't make it very far into reviewing this patch, because it looks
like xfrm_dev_state_flush() is called by the bonding driver's
notification handler, and I don't see that reflected in this patch?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
From: Peter Zijlstra @ 2026-01-26 21:35 UTC (permalink / raw)
To: Bart Van Assche
Cc: Marco Elver, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <8c1bbab4-4615-4518-b773-a006d1402b8b@acm.org>
On Mon, Jan 26, 2026 at 10:54:56AM -0800, Bart Van Assche wrote:
> Has it ever been considered to add support in the clang compiler for a
> variant of __must_hold() that expresses that one of two capabilities
> must be held by the caller? I think that would remove the need to
> annotate SRCU update-side code with __acquire_shared(ssp) and
> __release_shared(ssp).
Right, I think I've asked for logical operators like that. Although I
think it was in the __guarded_by() clause rather than the __must_hold().
Both || and && would be nice to have ;-)
Specifically, I think I asked for something like:
cpumask_t cpus_allowed __guarded_by(pi_lock && rq->__lock)
__guarded_shared_by(pi_lock || rq->__lock);
I think Marco's suggestion was to use 'fake' locks to mimic those
semantics.
^ permalink raw reply
* [ANN] Linux Security Summit 2026 CfP
From: James Morris @ 2026-01-26 20:58 UTC (permalink / raw)
To: linux-security-module
Cc: Linux Security Summit Program Committee, linux-kernel,
kernel-hardening, linux-integrity, lwn, linux-crypto, keyrings
=============================================================================
ANNOUNCEMENT AND CALL FOR PARTICIPATION
LINUX SECURITY SUMMIT NORTH AMERICA 2026
May 21-22
Minneapolis, MN, USA
==============================================================================
DESCRIPTION
Linux Security Summit North America (LSS-NA) 2026 is a technical forum for
collaboration between Linux developers, researchers, and end-users.
Its primary aim is to foster community efforts in deeply analyzing and
solving Linux operating system security challenges, including those in the
Linux kernel.
Proposals should be submitted via:
https://events.linuxfoundation.org/linux-security-summit-north-america/
SUGGESTED TOPICS
* Access Control
* Case Studies
* Cryptography and Key Management
* Emerging Technologies, Threats & Techniques
* Hardware Security
* IoT and Embedded Security
* Integrity Policy and Enforcement
* Open Source Supply Chain for the Linux OS
* Security Tools
* Security UX
* Linux OS Hardening
* Virtualization and Containers
DATES TO REMEMBER:
* CFP Close: Sunday, March 15 at 11:59 PM CDT
* CFP Notifications: Tuesday, March 31
* Schedule Announced: Thursday, April 2
* Event Date: Thursday, May 21 - Friday, May 22
WHO SHOULD ATTEND
We're seeking a diverse range of attendees and welcome participation by
people involved in Linux security development, operations, and research.
LSS is a unique global event that provides the opportunity to present and
discuss your work or research with key Linux security community members and
maintainers. It's also useful for those who wish to keep up with the latest
in Linux security development and to provide input to the development
process.
MASTODON
For event updates and announcements, follow:
https://social.kernel.org/LinuxSecSummit
#linuxsecuritysummit
PROGRAM COMMITTEE
The program committee for LSS 2026 is:
* James Morris, Microsoft
* Serge Hallyn, Geico
* Paul Moore, Microsoft
* Stephen Smalley, NSA
* Elena Reshetova, Intel
* John Johansen, Canonical
* Kees Cook, Google
* Casey Schaufler
* Mimi Zohar, IBM
* David A. Wheeler, Linux Foundation
The program committee may be contacted as a group via email:
lss-pc () lists.linuxfoundation.org
^ permalink raw reply
* Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
From: Bart Van Assche @ 2026-01-26 18:54 UTC (permalink / raw)
To: Marco Elver
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <aXez9fSxdfu5-Boo@elver.google.com>
On 1/26/26 10:35 AM, Marco Elver wrote:
> That being said, I don't think it's wrong to write e.g.:
>
> spin_lock(&updater_lock);
> __acquire_shared(ssp);
> ...
> // writes happen through rcu_assign_pointer()
> // reads can happen through srcu_dereference_check()
> ...
> __release_shared(ssp);
> spin_unlock(&updater_lock);
>
> , given holding the updater lock implies reader access.
>
> And given the analysis is opt-in (CONTEXT_ANALYSIS := y), I think
> it's a manageable problem.
I'd like to make context-analysis mandatory for the entire kernel tree.
> If you have a different idea how we can solve this, please let us know.
>
> One final note, usage of srcu_dereference_check() is rare enough:
>
> arch/x86/kvm/hyperv.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
> arch/x86/kvm/x86.c: kvm_free_msr_filter(srcu_dereference_check(kvm->arch.msr_filter, &kvm->srcu, 1));
> arch/x86/kvm/x86.c: kfree(srcu_dereference_check(kvm->arch.pmu_event_filter, &kvm->srcu, 1));
> drivers/gpio/gpiolib.c: label = srcu_dereference_check(desc->label, &desc->gdev->desc_srcu,
> drivers/hv/mshv_irq.c: girq_tbl = srcu_dereference_check(partition->pt_girq_tbl,
> drivers/hwtracing/stm/core.c: link = srcu_dereference_check(src->link, &stm_source_srcu, 1);
> drivers/infiniband/hw/hfi1/user_sdma.c: pq = srcu_dereference_check(fd->pq, &fd->pq_srcu,
> fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
> fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
> fs/quota/dquot.c: put[cnt] = srcu_dereference_check(dquots[cnt], &dquot_srcu,
> fs/quota/dquot.c: transfer_from[cnt] = srcu_dereference_check(dquots[cnt],
> include/linux/kvm_host.h: return srcu_dereference_check(kvm->memslots[as_id], &kvm->srcu,
> virt/kvm/irqchip.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
>
> , that I think it's easy enough to annotate these places with the above
> suggestions in case you're trying out global enablement.
Has it ever been considered to add support in the clang compiler for a
variant of __must_hold() that expresses that one of two capabilities
must be held by the caller? I think that would remove the need to
annotate SRCU update-side code with __acquire_shared(ssp) and
__release_shared(ssp).
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
From: Marco Elver @ 2026-01-26 18:35 UTC (permalink / raw)
To: Bart Van Assche
Cc: Peter Zijlstra, Boqun Feng, Ingo Molnar, Will Deacon,
David S. Miller, Luc Van Oostenryck, Chris Li, Paul E. McKenney,
Alexander Potapenko, Arnd Bergmann, Christoph Hellwig,
Dmitry Vyukov, Eric Dumazet, Frederic Weisbecker,
Greg Kroah-Hartman, Herbert Xu, Ian Rogers, Jann Horn,
Joel Fernandes, Johannes Berg, Jonathan Corbet, Josh Triplett,
Justin Stitt, Kees Cook, Kentaro Takeda, Lukas Bulwahn,
Mark Rutland, Mathieu Desnoyers, Miguel Ojeda, Nathan Chancellor,
Neeraj Upadhyay, Nick Desaulniers, Steven Rostedt, Tetsuo Handa,
Thomas Gleixner, Thomas Graf, Uladzislau Rezki, Waiman Long,
kasan-dev, linux-crypto, linux-doc, linux-kbuild, linux-kernel,
linux-mm, linux-security-module, linux-sparse, linux-wireless,
llvm, rcu
In-Reply-To: <dd65bb7b-0dac-437a-a370-38efeb4737ba@acm.org>
On Mon, Jan 26, 2026 at 09:31AM -0800, Bart Van Assche wrote:
> On 12/19/25 7:40 AM, Marco Elver wrote:
> > +/*
> > + * No-op helper to denote that ssp must be held. Because SRCU-protected pointers
> > + * should still be marked with __rcu_guarded, and we do not want to mark them
> > + * with __guarded_by(ssp) as it would complicate annotations for writers, we
> > + * choose the following strategy: srcu_dereference_check() calls this helper
> > + * that checks that the passed ssp is held, and then fake-acquires 'RCU'.
> > + */
> > +static inline void __srcu_read_lock_must_hold(const struct srcu_struct *ssp) __must_hold_shared(ssp) { }
> > /**
> > * srcu_dereference_check - fetch SRCU-protected pointer for later dereferencing
> > @@ -223,9 +233,15 @@ static inline int srcu_read_lock_held(const struct srcu_struct *ssp)
> > * to 1. The @c argument will normally be a logical expression containing
> > * lockdep_is_held() calls.
> > */
> > -#define srcu_dereference_check(p, ssp, c) \
> > - __rcu_dereference_check((p), __UNIQUE_ID(rcu), \
> > - (c) || srcu_read_lock_held(ssp), __rcu)
> > +#define srcu_dereference_check(p, ssp, c) \
> > +({ \
> > + __srcu_read_lock_must_hold(ssp); \
> > + __acquire_shared_ctx_lock(RCU); \
> > + __auto_type __v = __rcu_dereference_check((p), __UNIQUE_ID(rcu), \
> > + (c) || srcu_read_lock_held(ssp), __rcu); \
> > + __release_shared_ctx_lock(RCU); \
> > + __v; \
> > +})
>
> Hi Marco,
>
> The above change is something I'm not happy about. The original
> implementation of the srcu_dereference_check() macro shows that it is
> sufficient to either hold an SRCU reader lock or the updater lock ('c').
> The addition of "__srcu_read_lock_must_hold()" will cause compilation to
> fail if the caller doesn't hold an SRCU reader lock. I'm concerned that
> this will either lead to adding __no_context_analysis to SRCU updater
> code that uses srcu_dereference_check() or to adding misleading
> __assume_ctx_lock(ssp) annotations in SRCU updater code.
Right, and it doesn't help 'c' is an arbitrary condition. But it's
fundamentally difficult to say "hold either this or that lock".
That being said, I don't think it's wrong to write e.g.:
spin_lock(&updater_lock);
__acquire_shared(ssp);
...
// writes happen through rcu_assign_pointer()
// reads can happen through srcu_dereference_check()
...
__release_shared(ssp);
spin_unlock(&updater_lock);
, given holding the updater lock implies reader access.
And given the analysis is opt-in (CONTEXT_ANALYSIS := y), I think
it's a manageable problem.
If you have a different idea how we can solve this, please let us know.
One final note, usage of srcu_dereference_check() is rare enough:
arch/x86/kvm/hyperv.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
arch/x86/kvm/x86.c: kvm_free_msr_filter(srcu_dereference_check(kvm->arch.msr_filter, &kvm->srcu, 1));
arch/x86/kvm/x86.c: kfree(srcu_dereference_check(kvm->arch.pmu_event_filter, &kvm->srcu, 1));
drivers/gpio/gpiolib.c: label = srcu_dereference_check(desc->label, &desc->gdev->desc_srcu,
drivers/hv/mshv_irq.c: girq_tbl = srcu_dereference_check(partition->pt_girq_tbl,
drivers/hwtracing/stm/core.c: link = srcu_dereference_check(src->link, &stm_source_srcu, 1);
drivers/infiniband/hw/hfi1/user_sdma.c: pq = srcu_dereference_check(fd->pq, &fd->pq_srcu,
fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
fs/quota/dquot.c: put[cnt] = srcu_dereference_check(dquots[cnt], &dquot_srcu,
fs/quota/dquot.c: transfer_from[cnt] = srcu_dereference_check(dquots[cnt],
include/linux/kvm_host.h: return srcu_dereference_check(kvm->memslots[as_id], &kvm->srcu,
virt/kvm/irqchip.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
, that I think it's easy enough to annotate these places with the above
suggestions in case you're trying out global enablement.
^ 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