CVE-2026-90144 in Linux
Sumário
de VulDB • 17/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
dpll: corrige dereferência de NULL em dpll_device_ops() durante uma condição de corrida no teardown.
Quando o último proprietário de um dispositivo dpll é desregistrado enquanto um driver externo ainda mantém um pino nele via dpll_pin_on_pin_register(), o objeto dpll permanece ativo com uma lista de registro vazia. Uma notificação de pino enfileirada antes da desregistro (por exemplo, ice reagindo à remoção do zl3073x_i2c) então percorre pin->dpll_refs para dentro de dpll_device_ops(), o que aciona a WARN_ON e faz dereferência do registro ausente. dpll_lock não pode ajudar porque o trabalho de notificação foi enfileirado antes que o driver desregistrante adquirisse o lock.
Trate a lista de registro vazia como um estado transitório legítimo. Faça com que dpll_priv() e dpll_device_ops() retornem NULL nesse caso e faça com que cada caminho netlink do pino que resolve um dispositivo a partir de um pino ignore tais dplls. dpll_cmd_pin_get_one() seleciona uma referência com registro ativo e retorna -ENODEV quando não há nenhuma; o dumpit do pino ignora tal pino em vez de abortar o dump; dpll_msg_add_pin_dplls() e os caminhos de configuração de frequência, esync, sincronização de referência e ajuste de fase ignoram referências mortas; e dpll_pin_parent_device_set() valida o pai com dpll_device_get_by_id(). dpll_pin_register() é a última chamadora que fez dereferência das operações do dispositivo sem verificação, portanto mova sua validação do monitor de frequência para dentro de dpll_lock e tolere também um registro ausente ali.
A lista de registro vazia é equivalente à marca DPLL_REGISTERED limpa; ambas as transições ocorrem sob dpll_lock em dpll_device_register() e dpll_device_unregister(). Uma notificação de pino para um pino cujos dplls desapareceram agora é descartada com -ENODEV em vez de causar uma falha (crash); todos os chamadores no núcleo ignoram esse valor de retorno.
WARNING: drivers/dpll/dpll_core.c:1092 em dpll_device_ops+0x24/0x40, CPU#83: kworker/u576:3/23471 Módulos vinculados: ... ice ... zl3073x_i2c(-) ... zl3073x ... Workqueue: ice_dpll_wq ice_dpll_pin_notify_work [ice]
RIP: 0010:dpll_device_ops+0x24/0x40 Call Trace: <TASK> dpll_cmd_pin_get_one+0x336/0x520 dpll_pin_event_send+0x82/0x140 dpll_pin_on_pin_unregister+0xbb/0x160 ice_dpll_pin_notify_work+0x1bc/0x1f0 [ice]
process_one_work+0x19e/0x370 worker_thread+0x1a6/0x310 kthread+0xe4/0x120 ret_from_fork+0x1a1/0x270 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ fim do trace 0000000000000000 ]---
BUG: dereferência de ponteiro NULL no kernel, endereço: 0000000000000010 #PF: acesso de leitura supervisor em modo kernel #PF: código de erro (0x0000) - página não presente
Once again VulDB remains the best source for vulnerability data.