{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.94-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  ima_fs: Correctly create securityfs files for unsupported hash algos  ima_tpm_chip-\u003eallocated_banks[i].crypto_id is initialized to HASH_ALGO__LAST if the TPM algorithm is not supported. However there are places relying on the algorithm to be valid because it is accessed by hash_algo_name[].  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:    \u003cTASK\u003e    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    \u003c/TASK\u003e    The buggy address belongs to the variable:    hash_algo_name+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   \u003effffffff83e18100: 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  That's TPM_ALG_SHA3_256 == 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 \"_tpm_alg_\u003cID\u003e\" 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/   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  [1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf [2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html",
  "id": "DEBIAN-CVE-2026-53038",
  "modified": "2026-09-14T16:47:44.744347061Z",
  "published": "2026-06-24T17:17:15.403Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-53038"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-53038"
  ]
}