No kernel Linux, a seguinte vulnerabilidade foi resolvida. libceph: corrigir dois decodificadores nus inseguros no decode_lockers() decode_lockers() em cls_lock_client.c contém duas operações de decodificação que permitem que uma OSD maliciosa ou comprometida ativar a laje fora de limites lê: 1. ceph_decode_ 32 (p) no campo num_lockers não tem limites anteriores verificados. ceph_start_decoding() aceita struct_len= 0 como válido -- o interno ceph_decode_need( p, end, 0, ruim) sempre passa -- então quando um OSD envia struct_len= 0, ceph_start_decoding() retorna o sucesso com p == end. O ceph_decode_ descarado imediatamente a seguir 32 (p) então lê 4 bytes passam pelo limite do buffer validado. O valor do lixo é passado diretamente para o kzalloc_ objs() como contador de armários.
A função de frame_watchers() no osd_client.c já usa o ceph_decode_ 32 _safe() após a chamada ceph_start_decoding() própria. decode_lockers() foi o único site usando a variante nua. 2. ceph_decode_ 8 (p) após o loop decode_locker() não ter nenhum limite anterior verificado. Se um OSD ships num_lockers de tal forma que o loop avança p exatamente para terminar, o ceph_decode_ posterior nue_ 8 (p) lê um byte além do limite do buffer validado. O resultado é passado diretamente para o tipo *, que é usado como um discriminador de tipo de bloqueio por quem liga, dando uma leitura OOB de um Byte controlado por OSD com influência direta sobre o campo de tipo de bloqueio. Repare ambos substituindo as operações nuas com suas variantes seguras: ceph_decode_ 32 (p) -> ceph_decode_ 32 _safe( p, fim, *num_lockers, err_inval) ceph_decode_ 8 (p) -> ceph_decode_ 8 _siguro(p, fim, * tipo, err_free_lockers).
Os alvos do goto diferem intencionalmente: err_inval: é uma nova etiqueta retornando diretamente - EINVAL. É usado para o caminho de falha pré- alocação onde o *lockers ainda não está alocado e não deve ser passado para ceph_free_lockers(). err_free_ lockers: é a etiqueta existente. Ele é usado para o caminho de falha pós- alocação onde o *lockers é alocado e deve ser liberado. ret está configurado em -EINVAL antes do ceph_decode_ 8 _safe() para que err_free_lockers retorne o código de erro correto na violação dos limites. Sem isso, err_free_lockers retornaria um valor de ret estável ( 0 do loop decode_ locker() bem sucedido), engolindo silenciosamente o erro.
-EINVAL está correto para ambos os caminhos de falha. Os dados recebidos do OSD são estruturalmente mal-formados. - ENOMEM representaria mal a classe de falha para os chamados e para os backporters s stable@ triando caminhos de erro. Modelo de atacante: um OSD malicioso ou comprometido em uma implantação multi- locante Ceph pode desencadear isso contra qualquer cliente do kernel que emite o método lock.get_info (por exemplo, durante a aquisição exclusiva de bloqueio RBD). [ idryomov: ajuste de log de mudança, formatação ]. Registro de aconselhamento: GHSA- 7 xmj- 3 fxq- r 5 HP. Identificadores relacionados: CVE- 2026 - 68082.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 08 T 12: 30: 24.000 Z e lista a sua última modificação como 2026 - 08 - 23 T 15: 32: 56.000 Z. Gravidade: Crítico. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
Software afetado: o registro de aconselhamento não fornece um pacote normalizado ou faixa de versões. Classificação e evidência: nenhum identificador CWE está listado. O registro contém 9 suporte de referências nestes tipos: AVISO, WEB.