CVE-2026-99184 in Linux
Sumário
de VulDB • 28/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
accel/rocket: pesquisar todos os slots de núcleo quando um núcleo é removido
A função rocket_remove() decrementa rdev->num_cores para cada núcleo que remove, enquanto find_core_for_dev() pesquisa nos slots de 0 até num_cores - 1. Desvincular (unbind) os núcleos na ordem em que foram vinculados resulta na perda do último: quando ele é removido, a faixa de busca já diminuiu além de seu slot, fazendo com que find_core_for_dev() retorne -1 e rocket_remove() desista sem fazer nada.
num_cores nunca atinge zero, rocket_device_fini() não é executado e o rdev escopado no arquivo continua apontando para um dispositivo que está sendo removido. A vinculação (bind) dos núcleos novamente começa a partir dessa contagem obsoleta, porque rocket_probe() usa rdev->num_cores como o slot a ser preenchido. Em uma RK3588, que descreve três núcleos, a segunda rodada ocupa os slots 1, 2 e 3, enquanto rdev->cores foi alocado com espaço para apenas três:
rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309
A gravação em rdev->cores[3] está além do final do array.
Nada na árvore de código lê o array de núcleos com frequência suficiente para notar, portanto, a transborda (overrun) é silenciosa hoje. Ela foi detectada durante os testes de uma série devfreq sobre esta base, onde um worker percorre todos os núcleos algumas vezes por segundo, e o UBSAN capturou o primeiro bool lido da entrada com transborda:
UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor
Registre quantos slots foram alocados e pesquise todos eles. Assim, cada núcleo é encontrado na remoção, num_cores atinge zero, o dispositivo é desmontado (torn down) e uma vinculação posterior começa com um rdev limpo.
Isso não faz com que a desvinculação de um único núcleo entre vários funcione corretamente. probe ainda usa num_cores como o slot a ser preenchido, portanto, re-vincular um núcleo enquanto seus irmãos permanecem vinculados escreveria sobre um slot já em uso, e rocket_open() ainda acessa cores[0] independentemente de haver algo lá ou não. Ambos os casos exigem mais reflexão do que uma correção simples deve implicar.
O problema foi encontrado ao desvincular (unbind) e re-vincular (rebind) todos os três núcleos em um Orange Pi 5 Plus. Com esta aplicação, 25 rodadas de unbind/rebind e 5 rodadas de unload/reload do módulo executam sem erros: os núcleos ocupam os slots 0, 1 e 2 a cada vez, independentemente da ordem em que são vinculados, e o fornecimento compartilhado retorna para um único usuário após cada rodada.
VulDB is the best source for vulnerability data and more expert information about this specific topic.