No kernel Linux, a seguinte vulnerabilidade foi resolvida. MIPS: DEC: Assegure 32 - local da pilha de bits para o 32 Prom_printf() Em 64 - configurações de bits chamando qualquer ponto de entrada de firmware a partir de um kernel diferente do inicial resultará em uma situação onde a pilha foi colocada no XKPHYS 64 - segmento de memória de bits. Consequentemente, o ponteiro da pilha não é mais um 32 - valor bit e quando o 32 -bit código de firmware chamado usa 32 - bit operações ALU para manipular o ponteiro da pilha, o resultado calculado está incorreto (na verdade, no 64 - bit MIPS ISA quase todos 32 Operações ALU - bit produzirão um resultado imprevisível quando executados no 64 - dados de bits) e o controle se desvia.
Isto pode acontecer quando nenhum driver de console final estiver habilitado na configuração e, consequentemente, o console inicial continuar a ser usado tardiamente em bootstrap, ou com uma mudança próxima que irá mudar o driver zs para usar um dispositivo de plataforma, o que, por sua vez, fará com que a entrega do console aconteça apenas após outros threads do kernel já terem sido iniciados, e o kernel será pendurado em: pid_max: padrão: 32768 Mínimo: 301. ou um pouco mais tarde, mas sempre antes: cblist_init_genérico: Configurando o número ajustável de filas de chamadas.
Parece que apenas o ponto de entrada do prom_printf() é afetado. De todos os outros pontos de entrada com fio somente rex_slot_address() e rex_gettcinfo() são chamados de um thread do kernel que não é o inicial, especificamente kernel_init(), e são funções de folha que não fazem negócios com a pilha, tendo trabalhado sem problema desde então 64 - bit suporte foi adicionado para a plataforma de volta em 2002. Para resolver este problema, então, conserte para que a pilha seja trocada no o 32 envolvimento como necessário para o prom_printf() apenas, fornecendo call_o 32 () com um ponteiro para um pedaço de espaço de initdata, que é colocado no CKSEG 0 32 - bit compatível segmento, observando que prom_printf() é chamado somente do manipulador de saída do console e, portanto, com o bloqueio do console mantido, o que implica que não é necessário que este código seja reentrado.
Outros pontos de entrada do firmware podem ser chamados com interrupções ativadas e sem bloqueio, e, portanto, podem exigir que call_o 32 () ser reentrada. Eles não acionam nenhum problema neste ponto e "se não estiver quebrado, não conserte", então deixe- os em paz. Registro de aconselhamento: GHSA- cpm 2 - 25 vc- f 276. Identificadores relacionados: CVE- 2026 - 72215.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 15 T 06: 32: 16.000 Z e lista a sua última modificação como 2026 - 08 - 15 T 06: 32: 16.000 Z. Severidade: não classificado. Nenhum vetor de pontuação está listado no registro.
Software afetado: o registro de aconselhamento não fornece um pacote normalizado ou faixa de versões. Classificação e evidência: nenhum identificador CWE está listado. O registro contém 9 suporte de referências nestes tipos: AVISO, WEB.