From: Jonathan McDowell <noodles@earth.li>
To: dima@arista.com
Cc: Mimi Zohar <zohar@linux.ibm.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Eric Snowberg <eric.snowberg@oracle.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Silvia Sisinni <silvia.sisinni@polito.it>,
Enrico Bravi <enrico.bravi@polito.it>,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Dmitry Safonov <0x7f454c46@gmail.com>
Subject: Re: [PATCH v3] ima_fs: Avoid creating measurement lists for unsupported hash algos
Date: Tue, 27 Jan 2026 17:59:31 +0000 [thread overview]
Message-ID: <aXj9AwtTKVes5C38@earth.li> (raw)
In-Reply-To: <20260127-ima-oob-v3-1-1dd09f4c2a6a@arista.com>
On Tue, Jan 27, 2026 at 02:21:13PM +0000, Dmitry Safonov via B4 Relay wrote:
>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.
Can I suggest, for better consistency, it's tpm_alg_<id> (i.e. lower
case, like the rest of the path)?
>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
J.
--
"Why 'maybe' for everything?" "I'm using fluffy logic."
prev parent reply other threads:[~2026-01-27 18:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 14:21 [PATCH v3] ima_fs: Avoid creating measurement lists for unsupported hash algos Dmitry Safonov via B4 Relay
2026-01-27 17:59 ` Jonathan McDowell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aXj9AwtTKVes5C38@earth.li \
--to=noodles@earth.li \
--cc=0x7f454c46@gmail.com \
--cc=dima@arista.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=enrico.bravi@polito.it \
--cc=eric.snowberg@oracle.com \
--cc=jmorris@namei.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=silvia.sisinni@polito.it \
--cc=stable@vger.kernel.org \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox