Vulnerabilidad en kernel de Linux (CVE-2024-50250)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fsdax: dax_unshare_iter necesita copiar bloques enteros El código que copia datos de srcmap a iomap en dax_unshare_iter está muy, muy roto, lo que los cambios recientes de fsx de bfoster han expuesto. Si la posición y la longitud pasadas a dax_file_unshare no están alineadas con un límite de fsblock, la posición y la longitud de iter en la función _iter reflejarán esta desalineación. dax_iomap_direct_access siempre devuelve un puntero al inicio de la página fsdax kmapped, incluso si su argumento pos está en el medio de esa página. Esto es catastrófico para la integridad de los datos cuando iter->pos no está alineado con una página, porque daddr/saddr no apuntan al mismo byte en el archivo que iter->pos. Por lo tanto, corrompemos los datos del usuario copiándolos en el lugar equivocado. Si iter->pos + iomap_length() en la función _iter no está alineado con una página, entonces no copiamos un bloque completo y solo rellenamos parcialmente el bloque de destino. Esto es catastrófico para la confidencialidad de los datos porque exponemos contenidos pmem obsoletos. Solucione ambos problemas alineando copy_pos/copy_len con un límite de página (recuerde, esto es fsdax, por lo que 1 fsblock == 1 página base) de modo que siempre copiemos bloques completos. Aún no hemos terminado: no hay ninguna llamada a invalidate_inode_pages2_range, por lo que los programas que tienen el rango de archivos mmap seguirán accediendo al mapeo de memoria anterior después de que se hayan completado las actualizaciones de metadatos del archivo. Tenga cuidado con el valor de retorno: si la anulación del uso compartido tiene éxito, aún necesitamos devolver la cantidad de bytes en los que el iter iomap cree que estamos operando.