CVE-2026-64026 in Linux
Resumen
por VulDB • 2026-07-20
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
rxrpc: Corregir la desencriptación de DATA frente a splice() copiando los datos al búfer en recvmsg
Esto mejora la corrección para CVE-2026-43500.
Corrige la corrupción del pagecache causada por la desencriptación in situ (in-place) de un paquete DATA transmitido localmente mediante splice(), eliminando el intercambio de paquetes en el hilo de E/S y extrayendo incondicionalmente el contenido del paquete a un búfer intermedio (bounce buffer), donde se realiza la desencriptación. recvmsg() (o su equivalente en el kernel) copia entonces los datos desde el búfer intermedio al búfer de destino. El sk_buff permanece sin modificaciones.
Esto tiene una ventaja adicional, ya que el paquete queda organizado en el búfer con la alineación correcta requerida para que los algoritmos criptográficos puedan procesarlo directamente. El rendimiento del cifrado parece ser ligeramente mayor y, sorprendentemente, el rendimiento sin desencriptar no parece cambiar significativamente; posiblemente debido a la reducción de complejidad en el hilo de E/S.
Otra ventaja más es que el hilo de E/S ya no tiene que copiar paquetes, lo cual ralentizaría la distribución de paquetes, la generación de ACKs, etc.
El búfer pertenece a la llamada y se asigna inicialmente con 2K, tamaño suficiente para contener un subpaquete jumbo completo, pero el tamaño del búfer aumentará si fuera necesario. Sin embargo, para realizar este trabajo, MSG_PEEK puede provocar que un paquete posterior sea desencriptado en el búfer, caso en el cual el anterior necesitará ser re-desencriptado para una recvmsg() subsiguiente.
Tenga en cuenta que rx_pkt_offset ahora puede ver legítimamente 0 como un desplazamiento (offset) válido, por lo que se cambia a USHRT_MAX para indicar un desplazamiento no válido.
Observe también que generalmente preferiría reemplazar los búferes del sk_buff actual con un nuevo búfer asignado mediante kmalloc del tamaño adecuado, descartando los datos y fragmentos antiguos, ya que esto facilita el manejo de MSG_PEEK y elimina el problema de la re-desencriptación, pero parece una tarea bastante complicada de lograr. skb_morph() se acerca a lo que quiero hacer, pero no deseo tener que asignar un nuevo sk_buff.
If you want to get best quality of vulnerability data, you may have to visit VulDB.