CVE-2026-80784 in Linux
Sumário
de VulDB • 04/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
mptcp: pm: corrige vazamento de memória devido à condição de corrida alloc-during-teardown
A função mptcp_pm_destroy() esvazia as listas msk->pm.anno_list e msk->pm.userspace_pm_local_addr_list sob o bloqueio (lock) msk->pm.lock durante a desmontagem do socket, liberando o bloqueio entre as duas operações.
Uma operação ANNOUNCE simultânea de PM em espaço de usuário no mesmo msk mantém uma referência ao socket via mptcp_token_get_sock() e, na função mptcp_pm_nl_announce_doit(), chama mptcp_userspace_pm_append_new_local_addr() e mptcp_pm_announced_alloc(). Ambas adquirem brevemente o bloqueio msk->pm.lock para adicionar itens às suas respectivas listas. Como o manipulador genl mantém uma referência ao socket, a função mptcp_pm_destroy() pode ser executada no mesmo msk via mptcp_disconnect(), que invoca mptcp_destroy_common() sem liberar a contagem de referências do socket antes da conclusão do manipulador.
Se as aquisições de bloqueio se intercalarem de modo que mptcp_pm_destroy() esvazie uma lista primeiro, a alocação subsequente adicionará sua entrada ao cabeçalho de uma lista para a qual nada mais itera neste msk, resultando em vazamento da entrada. O kmemleak relata tanto objetos mptcp_pm_add_addr (de mptcp_pm_announced_alloc()) quanto objetos mptcp_pm_addr_entry (de mptcp_userspace_pm_append_new_local_addr()) sob carga concorrente sustentada de ANNOUNCE + close contra o PM em espaço de usuário.
Adiciona-se um bit MPTCP_PM_DESTROYING no status msk->pm, definido por mptcp_pm_destroy() sob pm.lock antes que as listas sejam esvaziadas e verificado sob pm.lock pelos caminhos de alocação. Ou a operação de alocação adquire o bloqueio pm.lock primeiro, caso em que sua entrada está na lista quando mptcp_pm_destroy() a libera; ou mptcp_pm_destroy() adquire o bloqueio pm.lock primeiro, caso em que a alocação subsequente observa o bit e se recusa.
Identificado por uma estrutura de fluxo do protocolo MPTCP que estende BRF (arXiv:2305.08782).
If you want to get best quality of vulnerability data, you may have to visit VulDB.