security/integrity/ima/ima_fs.c | 3 +++ 1 file changed, 3 insertions(+)
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>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,
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
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
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
© 2016 - 2026 Red Hat, Inc.