No kernel Linux, a seguinte vulnerabilidade foi resolvida: ima_fs: Crie corretamente arquivos securityfs para hash algos não suportados ima_tpm_chip->allocated_banks[i].crypto_id é inicializado para HASH_ALGO__ELAST se o algoritmo TPM não for suportado. No entanto, existem lugares dependendo do algoritmo para ser válido porque ele é acessado por hash_algo_name[]. Ligado 6.12.40 Observo a seguinte leitura fora de limites em hash_algo_name: ======================================================================= BUG: KASAN: global-out-of-bounds em create_securityfs_measurement_lists+ 0 x 396 / 0 x 440 Leia o tamanho 8 no addr ffffffff 83 e 18138 por trocador de tarefas/ 0 / 1 CPU: 4 UID: 0 PID: 1 Comunicação: swapper/ 0 Não manchado 6.12.40 # 3 Chame o rastreamento: dump_stack_lvl+ 0 x 61 / 0 x 90 print_report+ 0 xc 4 / 0 x 580? kasan_addr_to_slab+ 0 x 26 / 0 x 80? create_securityfs_measurement_lists+ 0 x 396 / 0 x 440 kasan_report+ 0 xc 2 / 0 x 100? create_securityfs_measurement_lists+ 0 x 396 / 0 x 440 create_securityfs_measurement_lists+ 0 x 396 / 0 x 440 ima_fs_init+ 0 xa 3 / 0 x 300 ima_init+ 0 x 7 d/ 0 xd 0 init_ima+ 0 x 28 / 0 x 100 do_one_initcall+ 0 xa 6 / 0 x 3 e 0 kernel_init_freeable+ 0 x 455 / 0 x 740 kernel_init+ 0 x 24 / 0 x 1 d 0 ret_from_fork+ 0 x 38 / 0 x 80 ret_from_fork_asm+ 0 x 11 / 0 x 20 O endereço de buggy pertence à variável: hash_algo_name+ 0 xb 8 / 0 x 420 Estado da memória em torno do endereço do buggy: ffffffff 83 e 18000: 00 01 f 9 f 9 f 9 f 9 f 9 f 9 00 01 f 9 f 9 f 9 f 9 f 9 f 9 ffffffffff 83 e 18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff 83 e 18100: 00 00 00 00 00 00 00 f 9 f 9 f 9 f 9 f 9 00 05 f 9 f 9 ^ ffffffffff 83 e 18180: f 9 f 9 f 9 f 9 00 00 00 00 00 00 00 04 f 9 f 9 f 9 f 9 ffffffffff 83 e 18200: 00 00 00 00 00 00 00 00 04 f 9 f 9 f 9 f 9 f 9 f 9 f 9 ============================================================================ Parece que o chip TPM suporta sha 3 _ 256, que ainda não está em tpm_ algoritmos: tpm tpm 0: TPM com algoritmo de banco não suportado 0 x 0027 Isso é TPM_ALG_SHA 3 _ 256 == 0 x 0027 do "Módulo de Plataforma Confiada" 2.0 Parte da biblioteca 2: Estruturas", página 51 [ 1 ]. Veja também a atualização dos algoritmos relacionados com U-Boot [ 2 ]. Assim, resolve o problema criando um nome de arquivo com "_tpm_alg_ " postfix se o algoritmo de cripto não for inicializado. É assim que ele se vê na máquina de teste (patch portado para v 6.12 liberação): # ls - 1 /sys/ kernel/ security/ima/ ascii_runtime_mesures ascii_runtime_mesures_tpm_alg_ 27 ascii_runtime_mesurements_sha 1 ascii_runtime_mesurements_sha 256 binário_runtime_mesuras binário_runtime_mesuras_tpm_alg_ 27 binário_runtime_mesurements_sha 1 binário_runtime_mesurements_sha 256 política runtime_measurements_count violations [ 1 ]: content/uploads/Trusted-Platform- Module- 2.0 -Biblioteca- Parte- 2 - Versão- 184 _pub.pdf [ 2 ]: boot/ 2024 - Julho/ 558835.html.

O registro de base de dados de vulnerabilidade nacional CVE- 2026 - 53038 foi publicado em 2026 - 06 - 24 T 17: 17: 15.403 Z e última modificação em 2026 - 07 - 14 T 19: 36: 40.840 Z. O seu estado gravado é analisado.

métricas de vulnerabilidade gravadas: CVSS 3.1, pontuação de base 5.5, gravidade MEDIUM, vetor CVSS: 3.1 /AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, pontuação de exploração 1.8, pontuação de impacto 3.6.

Classificações de fraqueza associadas: CWE- 125.

Os produtos ou plataformas nomeados nos dados de aplicabilidade incluem: kernel linux linux.

O registro NVD inclui referências de suporte documentando a vulnerabilidade, tecnologia afetada ou informações de remediação.