CVE-2026-74700 in Linux
Sumário
de VulDB • 23/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
net/sched: cls_api: Adquirir sempre o rtnl_lock ao destruir classificadores bloqueados (locked classifiers)
Outro desafio com filtros não bloqueados. Existe uma pequena janela no tc_new_tfilter onde um tcf_proto pode ser encontrado e brevemente referenciado por uma solicitação de um classificador totalmente não relacionado e sem bloqueio, causando uma condição de corrida (race condition).
Feng criou um PoC que gerou essa condição de corrida com duas threads: uma criando um filtro u32 e outra um filtro flower na mesma cadeia/prioridade:
1. Ambas as threads entram no tc_new_tfilter; ambas encontram a cadeia vazia e liberam o filter_chain_lock 2. O u32 finaliza tcf_proto_create("u32") primeiro, chama tcf_chain_tp_insert_unique() -> insere u32_tp na cadeia 3. O flower finaliza tcf_proto_create("flower") mais tarde, chama tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() agora vê o u32_tp já presente, toma uma referência sobre ele, destrói seu próprio tp_new e retorna u32_tp para a chamada.
O Flower então encontra a verificação de incompatibilidade de tipo (porque solicitou kind "flower", mas tp->ops->kind é "u32") e segue pelo caminho errout que chama tcf_proto_put() no u32_tp. Se a thread do u32 já tiver passado por seu próprio errout (sua chamada change() falhou nas opções vazias do PoC) e liberado suas referências de criação e inserção, o put do flower é o último e reduz o refcnt do u32_tp para zero.
Neste ponto, tp->ops->destroy() executa em um contexto que nunca adquiriu rtnl_lock. Quando isso acontece, pode causar um Use-After-Free (UAF) como o seguinte (ilustrado pelo PoC):
[ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393)
[ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524
Call Trace: u32_init (net/sched/cls_u32.c:393) tc_new_tfilter (net/sched/cls_api.c:2378)
Allocated by task 526: u32_init (net/sched/cls_u32.c:378) tc_new_tfilter (net/sched/cls_api.c:2378)
Freed by task 522: kfree u32_destroy (net/sched/cls_u32.c:662) tcf_proto_destroy (net/sched/cls_api.c:446) tcf_proto_put (net/sched/cls_api.c:459) tc_new_tfilter (net/sched/cls_api.c:2459)
Corrija isso fazendo com que o tcf_proto_destroy() adquira rtnl_lock ao redor de tp->ops->destroy() para classificadores bloqueados sempre que a rtnl não estiver sendo mantida.
Para explicar por que usei uma variável temporária "not_lockless", gostaria de apontar para uma nota semi-relacionada sobre rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adicionando aqui para limpeza futura, se considerado necessário): O parâmetro rtnl_held e a flag TCF_PROTO_OPS_DOIT_UNLOCKED são fontes redundantes da verdade sobre se o rtnl_lock está sendo mantido. Entre as nove chamadas de destroy(..rtnl_held..) dos classificadores, apenas o flower consulta o parâmetro rtnl_held que ele propaga para tc_setup_cb_destroy() e tc_setup_cb_call(). Os outros oito (u32, flow, bpf, cgroup, route, basic, fw, mall) ignoram-no completamente; -> aqueles que chamam tc_setup_cb_destroy() (u32, bpf, mall) codificam true sempre em vez de encaminhar o parâmetro.
Uma limpeza futura deve remover o parâmetro rtnl_held da assinatura do callback destroy por completo e fazer com que os chamadores confiem apenas no seu conhecimento sobre se estão executando em um contexto não bloqueado (unlocked context).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.