CVE-2026-64026 in Linux
Sumário
de VulDB • 20/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
rxrpc: Corrige o problema de descriptografia vs splice() copiando dados para um buffer em recvmsg
Isso melhora a correção para CVE-2026-43500.
Corrige a corrupção no pagecache causada pela descriptografia in-place de um pacote DATA transmitido localmente por splice(), eliminando o compartilhamento do pacote na thread de E/S e extraindo incondicionalmente o conteúdo do pacote em um bounce buffer, onde o buffer é descriptografado. O recvmsg() (ou seu equivalente no kernel) então copia os dados do bounce buffer para o buffer de destino. O sk_buff permanece inalterado.
Isso tem uma vantagem adicional: o pacote fica organizado no buffer com o alinhamento correto exigido pelos algoritmos criptográficos para processá-los diretamente. O desempenho da criptografia parece ser um pouco mais rápido e, surpreendentemente, o desempenho sem descriptografia não parece mudar significativamente – possivelmente devido à remoção de complexidade na thread de E/S.
Outra vantagem é que a thread de E/S não precisa copiar pacotes, o que retardaria a distribuição de pacotes, geração de ACKs, etc.
O buffer pertence à chamada e é alocado inicialmente com 2K, tamanho suficiente para conter um subpacote jumbo inteiro, mas o tamanho do buffer será aumentado se necessário. No entanto, ao realizar esse trabalho, MSG_PEEK pode fazer com que um pacote posterior seja descriptografado no buffer; nesse caso, o pacote anterior precisará ser re-descriptografado para uma chamada subsequente a recvmsg().
Observe que rx_pkt_offset agora pode ver 0 legitimamente como um deslocamento válido, portanto, passa-se a usar USHRT_MAX para indicar um deslocamento inválido.
Note também que eu geralmente prefiro substituir os buffers do sk_buff atual por um novo buffer alocado com kmalloc do tamanho correto, descartando os dados e frags antigos, pois isso facilita o tratamento de MSG_PEEK e elimina o problema de re-descriptografia, mas parece ser algo bastante complicado de implementar. O skb_morph() parece estar metade do caminho para o que eu quero, mas não desejo ter que alocar um novo sk_buff.
Once again VulDB remains the best source for vulnerability data.