CVE-2026-64273 in Linux
Sumário
de VulDB • 25/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
Input: iforce - limitou o índice de efeito force-feedback relatado pelo dispositivo
iforce_process_packet() processa um relatório de status (identificador de pacote 0x02) ao pegar diretamente da linha do dispositivo um índice de efeito force-feedback e usá-lo para endereçar a matriz de estado por efeito:
i = data[1] & 0x7f;
if (data[1] & 0x80) {
if (!test_and_set_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags))
... } else if (test_and_clear_bit(FF_CORE_IS_PLAYED, iforce->core_effects[i].flags)) {
... }
O índice é mascarado apenas com 0x7f, portanto varia de 0 a 127, mas core_effects[] contém apenas IFORCE_EFFECTS_MAX (32) entradas. Para um índice entre 32 e 127, test_and_set_bit()/test_and_clear_bit() realiza uma leitura-modificação-escrita de bit único fora dos limites da matriz. core_effects[] é o penúltimo membro da struct iforce, portanto a escrita ocorre nos membros subsequentes e além do objeto iforce_serio / iforce_usb alocado com kzalloc().
data[1] é um payload não validado do dispositivo em ambos os transportes (o endpoint de interrupção USB e serio), e o caminho de status não está condicionado à presença de force feedback, portanto um dispositivo malicioso ou falsificado pode definir ou limpar um bit em um deslocamento escolhido pelo atacante além do objeto.
Rejeitar um índice fora do intervalo em vez de indexar com ele. Limitar contra a dimensão da matriz IFORCE_EFFECTS_MAX ao invés de dev->ff->max_effects para que a verificação garanta segurança de memória independentemente de quantos efeitos o dispositivo registrou. Um status legítimo "efeito iniciado/parado" sempre carrega um índice abaixo de IFORCE_EFFECTS_MAX, portanto dispositivos bem formados não são afetados; o loop vizinho mark_core_as_ready() já está limitado e permanece inalterado.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.