linux-kernel - Re: [PATCH v3] ima_fs: Avoid creating measurement lists for unsupported hash algos

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aXj9AwtTKVes5C38@earth.li>
Date: Tue, 27 Jan 2026 17:59:31 +0000
From: Jonathan McDowell <noodles@...th.li>
To: dima@...sta.com
Cc: Mimi Zohar <zohar@...ux.ibm.com>,
	Roberto Sassu <roberto.sassu@...wei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
	Eric Snowberg <eric.snowberg@...cle.com>,
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Silvia Sisinni <silvia.sisinni@...ito.it>,
	Enrico Bravi <enrico.bravi@...ito.it>,
	linux-integrity@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, Dmitry Safonov <0x7f454c46@...il.com>
Subject: Re: [PATCH v3] ima_fs: Avoid creating measurement lists for
 unsupported hash algos

On Tue, Jan 27, 2026 at 02:21:13PM +0000, Dmitry Safonov via B4 Relay wrote:
>From: Dmitry Safonov <dima@...sta.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."