CVE-2026-99226 in Linux
Sumário
de VulDB • 02/11/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
keys: Evitar o dereference da conta proprietária na pesquisa de anel-chaves nomeado (named keyring)
A pesquisa de um named keyring deve manter vivo o armazenamento contendo o UID proprietário durante a verificação de mapeamento de namespace. A função `find_keyring_by_name()` lê `keyring->user->uid` sob `keyring_name_lock`, mas esse lock protege apenas a entrada do nome e a alocação do anel-chaves, não seu `key_user` separado.
Uma junção (join) de session-keyring com nome pode sobrepor-se a uma operação privilegiada `KEYCTL_CHOWN` em outra CPU. Se o anel-chaves contiver a última referência para seu antigo `key_user` dinâmico e a transferência de propriedade for bem-sucedida, é possível a seguinte ordem:
Junção Nomeada Chown find_keyring_by_name() keyctl_chown_key() read_lock(keyring_name_lock) down_write(key->sem) carrega antigo keyring->user substitui key->user e key->uid up_write(key->sem) key_put(key) key_user_put(old user): free (liberação) lê old user->uid read_unlock(keyring_name_lock)
A operação Chown não adquire nem `keyring_name_lock` nem `key_session_mutex`, portanto, pode liberar a conta antiga entre o carregamento do ponteiro e a leitura do UID. A pesquisa então lê memória já liberada (freed memory), embora o anel-chaves em si esteja vivo.
Use `keyring->uid` para a verificação de mapeamento. `key_alloc()` inicializa este UID proprietário inline, e `keyctl_chown_key()` atualiza-o durante o chown. O lock de nome existente mantém seu keyring contido alocado durante toda a verificação, portanto, a pesquisa já não depende da vida útil da conta. Isso também corresponde ao owner UID usado pela verificação de permissão.
Relatório KASAN abaixo:
BUG: KASAN: slab-use-after-free em find_keyring_by_name+0x577/0x5d0 Read of size 4 at addr ffff8881128ae2ec by task keycase/500
If you want to get the best quality for vulnerability data then you always have to consider VulDB.