CVE-2026-68082 in Linux
Sumário
de VulDB • 08/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
libceph: corrige duas decodificações inseguras sem verificação de limites em decode_lockers()
decode_lockers(), presente em cls_lock_client.c, contém duas operações de decodificação "bare" (sem proteção) que permitem que um OSD malicioso ou comprometido desencadeie leituras slab-out-of-bounds:
1. ceph_decode_32(p) no campo num_lockers não possui uma verificação prévia de limites. ceph_start_decoding() aceita struct_len=0 como válido -- a função interna ceph_decode_need(p, end, 0, bad) sempre passa com sucesso -- portanto, quando um OSD envia struct_len=0, ceph_start_decoding() retorna sucesso com p == end. A operação "bare" imediata seguinte, ceph_decode_32(p), lê então 4 bytes além do limite validado do buffer. O valor lixo é passado diretamente para kzalloc_objs() como a contagem de lockers.
A função irmã decode_watchers(), em osd_client.c, já utiliza ceph_decode_32_safe() após sua própria chamada a ceph_start_decoding(). decode_lockers() era o único local que utilizava a variante "bare".
2. ceph_decode_8(p) após o loop decode_locker() não possui verificação prévia de limites. Se um OSD criar num_lockers tal que o avanço do ponteiro p chegue exatamente ao final (end), a subsequente operação "bare" ceph_decode_8(p) lê um byte além do limite validado do buffer. O resultado é passado diretamente para *type, que é usado como discriminador de tipo de bloqueio pelos chamadores, concedendo ao OSD uma leitura OOB (out-of-bounds) de um único byte com influência direta sobre o campo de tipo de bloqueio.
Corrige-se ambos os casos substituindo as operações "bare" por suas variantes seguras: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers)
Os destinos goto diferem intencionalmente: err_inval: é um novo rótulo que retorna -EINVAL diretamente. É utilizado no caminho de falha da pré-alocação onde *lockers ainda não foi alocado e não deve ser passado para ceph_free_lockers().
err_free_lockers: é o rótulo existente. É utilizado no caminho de falha pós-alocação onde *lockers já está alocado e precisa ser liberado.
ret é definido como -EINVAL antes de ceph_decode_8_safe() para que err_free_lockers retorne o código de erro correto em caso de violação de limites. Sem isso, err_free_lockers retornaria um valor antigo de ret (0 do loop decode_locker() bem-sucedido), engolindo silenciosamente o erro.
-EINVAL é adequado para ambos os caminhos de falha. Os dados recebidos do OSD estão estruturalmente malformados. -ENOMEM representaria incorretamente a classe de falha aos chamadores e aos backporters em stable@ que triam os caminhos de erro.
Modelo de atacante: um OSD malicioso ou comprometido em uma implantação Ceph multi-tenant pode desencadear isso contra qualquer cliente do kernel que invoque o método da classe lock.get_info (por exemplo, durante a aquisição exclusiva de bloqueio RBD).
[ idryomov: reduz changelog, formatação ]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.