No kernel Linux, a seguinte vulnerabilidade foi resolvida: x 86 /mce: use is_copy_from_user() para determinar o contexto de cópia do usuário Série de parches "mm/hwpoison: corrigir regressões no manuseio de falhas de memória", v 4. ## 1. O que estou tentando fazer: Este conjunto de patchs resolve duas regressões críticas relacionadas ao manuseamento de falhas de memória que apareceram no kernel a montante desde a versão 5.17, em comparação com 5.10 LTS. - caso de copia: veneno encontrado na página do usuário enquanto o kernel copia do espaço do usuário - caso de instr: veneno encontrado enquanto as instruções buscam no espaço do usuário ## 2. Qual é o resultado esperado e por quê - Para o caso de copyin: o kernel pode recuperar do veneno encontrado onde o kernel está fazendo get_user() ou copy_from_user() se esses lugares receberem um retorno de erro e o kernel retorna - EFAULT ao processo em vez de falhar. Mais especificamente, o manipulador MCE verifica o tipo de manipulador de fixação para decidir se um no #MC do kernel pode ser recuperado. Quando EX_ TYPE_ UACCESS for encontrado, o PC salta para o código de recuperação especificado em _ ASM_ EXTABLE_ FAULT() e retorna um - EFAULT para o espaço de usuário. - Para o caso do instr: Se um veneno encontrado enquanto as instruções estão captando no espaço de usuário, é possível recuperar completamente. O processo do usuário leva o #PF, o Linux aloca uma página nova e preenche a leitura do armazenamento. ## 3. O que realmente acontece e por quê - Para o caso do copyin: pânico do kernel desde o v 5.17 Commit 4 c 132 d 1 d 844 a (" x) 86 /futex: Remover o uso.fixup") introduziu um novo tipo de fixação extable, EX_TYPE_EFAULT_ REG, e os patches posteriores atualizaram o tipo de fixação extable para operações de cópia- do- usuário, mudando- o de EX_TYPE_UACCESS para EX_TYPE_EFAULT_ REG. Ele quebra o tratamento anterior do EX_TYPE_UACCESS quando a posição encontrada em get_user() ou copy_from_user(). - Para o caso instr: o processo do usuário é destruído por um sinal SIGBUS devido à corrida #CMCI e #MCE Quando um erro de memória não corrigido é consumido há uma corrida entre o CMCI do controlador de memória relatando um erro não corrigido com uma assinatura UCNA, e o núcleo de relatório e a máquina de assinatura SRAR verificam quando os dados estão prestes a ser consumidos. ### Fundo: por que *UN* erros corrigidos ligados a *C*MCI na plataforma Intel [ 1 ] Antes do Icelake os controladores de memória relataram eventos de esfregamento de patrulha que detectaram um erro não corrigido anteriormente no banco de verificação da máquina, sinalizando uma verificação de máquina de transmissão com uma assinatura SRAO (Software Recoverable Action Opcional) no banco de verificação da máquina. Isto foi exagerado porque não é um problema urgente que nenhum núcleo esteja à beira de consumir esses dados ruins. Também foi encontrado que o Multi SRAO UCE pode causar interrupções do MCE aninhado e finalmente se tornar um IERR. Assim, o Intel baixa a assinatura do banco de verificação da máquina da patrulha de SRAO para UCNA (não corrigida, sem ação necessária), e o sinal mudou para #CMCI. Apenas para adicionar à confusão, o Linux toma uma ação (no uc_decode_notifier()) para tentar desligar a página apesar do nome de assinatura UC*NA*. ### Fundo: por que #CMCI e #MCE correm quando veneno está consumindo na plataforma Intel [ 1 ] Tendo decidido que CMCI/UCNA é a melhor ação para erros de limpeza de patrulhas, o controlador de memória usa- a para ler também. Mas o controlador de memória está executando assíncronamente a partir do núcleo, e não pode distinguir a diferença entre uma leitura "real" e uma leitura especulativa. Assim, ele fará CMCI/UCNA se um erro for encontrado em qualquer leitura. Assim: 1 ) O núcleo é inteligente e pensa que o endereço A é necessário em breve, emissões uma leitura especulativa. 2 ) O núcleo encontra que vai usar o endereço A logo após enviar o pedido de leitura 3 ) O CMCI do controlador de memória está numa corrida com MCE do núcleo que logo tentará retirar a carga do endereço A. Muitas vezes (porque a especulação melhorou) o CMCI do controlador de memória é entregue antes que o núcleo seja comprometido com o endereço de leitura da instrução A, então a interrupção é tomada, e Linux desliga a página (marcando-a como veneno). ## Por que o processo do usuário é morto para o caso Instr Commit 046545 a 661 af ("mm/hwpoison: correção página de erro recuperada mas relatada "não truncado---.
O registro de base de dados de vulnerabilidade nacional CVE- 2025 - 39989 foi publicado em 2025 - 04 - 18 T 07: 15: 44.550 Z e última modificação em 2026 - 06 - 17 T 09: 18: 58.037 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- 401.
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.