CVE-2026-53038

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima_fs: Correctly create securityfs files for unsupported hash algos<br /> <br /> ima_tpm_chip-&gt;allocated_banks[i].crypto_id is initialized to<br /> HASH_ALGO__LAST if the TPM algorithm is not supported. However there<br /> are places relying on the algorithm to be valid because it is accessed<br /> by hash_algo_name[].<br /> <br /> On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:<br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440<br /> Read of size 8 at addr ffffffff83e18138 by task swapper/0/1<br /> <br /> CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x61/0x90<br /> print_report+0xc4/0x580<br /> ? kasan_addr_to_slab+0x26/0x80<br /> ? create_securityfs_measurement_lists+0x396/0x440<br /> kasan_report+0xc2/0x100<br /> ? create_securityfs_measurement_lists+0x396/0x440<br /> create_securityfs_measurement_lists+0x396/0x440<br /> ima_fs_init+0xa3/0x300<br /> ima_init+0x7d/0xd0<br /> init_ima+0x28/0x100<br /> do_one_initcall+0xa6/0x3e0<br /> kernel_init_freeable+0x455/0x740<br /> kernel_init+0x24/0x1d0<br /> ret_from_fork+0x38/0x80<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> <br /> The buggy address belongs to the variable:<br /> hash_algo_name+0xb8/0x420<br /> <br /> Memory state around the buggy address:<br /> ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9<br /> ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9<br /> ^<br /> ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9<br /> ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9<br /> ==================================================================<br /> <br /> Seems like the TPM chip supports sha3_256, which isn&amp;#39;t yet in<br /> tpm_algorithms:<br /> tpm tpm0: TPM with unsupported bank algorithm 0x0027<br /> <br /> That&amp;#39;s TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0<br /> Library Part 2: Structures", page 51 [1].<br /> See also the related U-Boot algorithms update [2].<br /> <br /> Thus solve the problem by creating a file name with "_tpm_alg_"<br /> postfix if the crypto algorithm isn&amp;#39;t initialized.<br /> <br /> This is how it looks on the test machine (patch ported to v6.12 release):<br /> # ls -1 /sys/kernel/security/ima/<br /> ascii_runtime_measurements<br /> ascii_runtime_measurements_tpm_alg_27<br /> ascii_runtime_measurements_sha1<br /> ascii_runtime_measurements_sha256<br /> binary_runtime_measurements<br /> binary_runtime_measurements_tpm_alg_27<br /> binary_runtime_measurements_sha1<br /> binary_runtime_measurements_sha256<br /> policy<br /> runtime_measurements_count<br /> violations<br /> <br /> [1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf<br /> [2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html