CVE-2026-53038: ima_fs: Correctly create securityfs files for unsupported hash algos
In the Linux kernel, the following vulnerability has been resolved:
imafs: Correctly create securityfs files for unsupported hash algos
imatpmchip->allocatedbanks[i].cryptoid is initialized to HASHALGOLAST if the TPM algorithm is not supported. However there are places relying on the algorithm to be valid because it is accessed by hashalgoname[].
On 6.12.40 I observe the following read out-of-bounds in hashalgoname: ================================================================== BUG: KASAN: global-out-of-bounds in createsecurityfsmeasurementlists+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> dumpstacklvl+0x61/0x90 printreport+0xc4/0x580 ? kasanaddrtoslab+0x26/0x80 ? createsecurityfsmeasurementlists+0x396/0x440 kasanreport+0xc2/0x100 ? createsecurityfsmeasurementlists+0x396/0x440 createsecurityfsmeasurementlists+0x396/0x440 imafsinit+0xa3/0x300 imainit+0x7d/0xd0 initima+0x28/0x100 dooneinitcall+0xa6/0x3e0 kernelinitfreeable+0x455/0x740 kernelinit+0x24/0x1d0 retfromfork+0x38/0x80 retfromforkasm+0x11/0x20 </TASK>
The buggy address belongs to the variable: hashalgoname+0xb8/0x420
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 sha3256, which isn't yet in tpmalgorithms: tpm tpm0: TPM with unsupported bank algorithm 0x0027
That's TPMALGSHA3256 == 0x0027 from "Trusted Platform Module 2.0 Library Part 2: Structures", page 51 [1]. See also the related U-Boot algorithms update [2].
Thus solve the problem by creating a file name with "tpmalg<ID>" postfix if the crypto algorithm isn't initialized.
This is how it looks on the test machine (patch ported to v6.12 release): # ls -1 /sys/kernel/security/ima/ asciiruntimemeasurements asciiruntimemeasurementstpmalg27 asciiruntimemeasurementssha1 asciiruntimemeasurementssha256 binaryruntimemeasurements binaryruntimemeasurementstpmalg27 binaryruntimemeasurementssha1 binaryruntimemeasurementssha256 policy runtimemeasurementscount violations
[1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184pub.pdf [2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (IMA/securityfs)to a version that resolves this vulnerability.Fixed in 6.12.40 - Configuration
Create the securityfs file name with "_tpm_alg_<ID>" (e.g., "ascii_runtime_measurements_tpm_alg_27" / "binary_runtime_measurements_tpm_alg_27") so IMA does not index/assume hash_algo_name[] entries for unsupported TPM algorithms. This aligns with the described change: "ima_fs: Correctly create securityfs files for unsupported hash algos" and the fix that "Thus solve the problem by creating a file name with \"_tpm_alg_<ID>\"".
IMA securityfs (ima_fs / create_securityfs_measurement_lists) filename format for runtime measurements per TPM algorithm = Use suffix "_tpm_alg_<ID>" for unsupported TPM algorithm IDs (ID=0x0027 => "_tpm_alg_27" as indicated) - Compensating control
If the system has a TPM chip with unsupported bank algorithm TPM_ALG_SHA3_256 == 0x0027 (e.g., sha3_256), ensure IMA does not create/serve measurement securityfs files that rely on missing hash algorithm definitions; the kernel fix described below specifically handles unsupported hash algos.