CVE-2026-53038

What it actually does

This Linux kernel flaw is a global out-of-bounds read in the Integrity Measurement Architecture (IMA) securityfs initialization path. When a TPM exposes a measurement bank using an algorithm the kernel does not recognize, the kernel initializes the bank's crypto identifier to an invalid sentinel value but later uses it as an index into the hash algorithm name table. On affected systems, this can cause an out-of-bounds memory read during creation of IMA measurement list files under securityfs, typically during early boot or IMA initialization. The most likely technical outcome is a kernel warning, KASAN finding, or boot-time kernel crash/panic depending on kernel build and panic policy; practical remote code execution is not indicated by the available information.

Why it matters to the business

The primary business risk is system availability and reliability for Linux hosts using TPM-backed IMA where the TPM advertises newer or unsupported hash algorithms, such as SHA3-256. Affected systems may fail to boot cleanly, panic during initialization, or produce integrity subsystem errors, which can disrupt servers, appliances, embedded systems, and measured-boot or compliance workflows. The issue is not listed in CISA KEV, has very low EPSS, is not known to be used in ransomware campaigns, and has no reported exploit maturity, so urgency is driven mainly by operational exposure rather than active exploitation.

How an attack unfolds

An attacker would need a way to cause the kernel to encounter an unsupported TPM measurement bank algorithm during IMA initialization. In a realistic scenario, this is usually a hardware, firmware, virtual TPM, or platform configuration condition rather than a remotely triggerable attack. During boot, the kernel enumerates TPM allocated banks; if one maps to an unsupported algorithm, the IMA securityfs code may still attempt to derive a filename using the invalid hash algorithm identifier. That invalid identifier is then used to index the kernel hash algorithm name array, resulting in an out-of-bounds read. On hardened/debug kernels this is detected by KASAN and may trigger a panic; on production kernels the effect may be a boot-time failure, kernel warning, or unstable IMA securityfs initialization. There is no public indication that threat actors are exploiting this vulnerability in the wild.

How to fix it

Upgrade to a Linux kernel release that includes the fix for IMA securityfs handling of unsupported TPM hash algorithms. The corrected behavior creates measurement list filenames using a generic TPM algorithm suffix, such as `_tpm_alg_<ID>`, when the kernel cannot map the TPM algorithm to a known crypto hash name. If vendor kernels are used, apply the distribution or appliance vendor's kernel update rather than attempting to backport manually. Where immediate patching is not possible, reduce exposure by avoiding TPM/vTPM configurations that advertise unsupported banks, disabling unsupported TPM banks in firmware where supported, or temporarily disabling IMA/TPM measurement features only if acceptable for the system's security and compliance requirements. Avoid disabling integrity measurement controls as a long-term mitigation.

How to confirm the fix worked

Confirm that the running kernel includes the vendor fix by checking the installed kernel package changelog or upstream stable release notes for the IMA securityfs unsupported TPM algorithm fix. Reboot into the updated kernel and review kernel logs for absence of `KASAN: global-out-of-bounds in create_securityfs_measurement_lists` and related IMA initialization failures. On systems with unsupported TPM banks, verify that `/sys/kernel/security/ima/` contains measurement files using the generic suffix format, for example `ascii_runtime_measurements_tpm_alg_27` or `binary_runtime_measurements_tpm_alg_27`, rather than causing a crash or warning. Also verify that IMA files such as `runtime_measurements_count`, `violations`, and `policy` remain accessible after boot.

Typical attack path

1. Gain control over, or influence, TPM/vTPM firmware, platform firmware, virtual machine TPM configuration, or hardware presented to the Linux kernel.
2. Configure or expose a TPM measurement bank using an algorithm not supported by the kernel TPM algorithm mapping, such as TPM_ALG_SHA3_256 / 0x0027 on affected kernels.
3. Boot or initialize the affected Linux kernel with IMA and securityfs enabled.
4. Allow IMA initialization to create runtime measurement list files for TPM banks.
5. Trigger the invalid hash algorithm identifier to be used as an index into the hash algorithm name table.
6. Cause a kernel out-of-bounds read, potentially resulting in a KASAN report, kernel warning, boot failure, or panic depending on system configuration.

How to detect it

Look for evidence of boot-time kernel faults during IMA initialization and TPM bank enumeration. Relevant log sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, serial console logs, crash dumps, pstore/ramoops records, and hypervisor console logs for virtual machines. Search for KASAN reports referencing `create_securityfs_measurement_lists`, `ima_fs_init`, `hash_algo_name`, or `global-out-of-bounds`, especially near TPM messages indicating an unsupported bank algorithm. Also search for `TPM with unsupported bank algorithm 0x0027`, which indicates exposure to the triggering condition observed in the report. If kernel panic or crash collection is enabled, inspect vmcore, kdump, pstore, and boot-failure artifacts for call traces involving IMA initialization. There are no known threat actor tradecraft indicators or post-exploitation artifacts specific to this vulnerability; detections are primarily reliability and exposure indicators rather than proof of compromise.

• KASAN: global-out-of-bounds in create_securityfs_measurement_lists
• global-out-of-bounds in create_securityfs_measurement_lists
• Read of size 8 at addr
• hash_algo_name
• ima_fs_init
• ima_init
• init_ima
• TPM with unsupported bank algorithm 0x0027
• TPM_ALG_SHA3_256
• /sys/kernel/security/ima/ascii_runtime_measurements_tpm_alg_27
• /sys/kernel/security/ima/binary_runtime_measurements_tpm_alg_27

What your security team should do

• Prioritize patching Linux systems that use TPM-backed IMA, measured boot, secure boot attestation, virtual TPMs, or custom hardware/firmware TPM configurations.
• Inventory systems with TPM 2.0 enabled and review boot logs for unsupported TPM bank algorithms, especially `0x0027` / SHA3-256.
• Apply vendor kernel updates through the normal OS distribution or appliance update channel and reboot into the fixed kernel.
• For systems that cannot be patched immediately, evaluate whether unsupported TPM banks can be disabled in firmware, hypervisor, or vTPM configuration without weakening required attestation controls.
• Monitor kernel logs after patching to confirm IMA initializes successfully and no KASAN or out-of-bounds warnings are present.
• Treat this as a reliability and platform-hardening issue rather than an active exploitation emergency unless local threat models include malicious firmware, hostile hypervisor control, or untrusted TPM/vTPM provisioning.