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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: se corrige la corrupción de mapas de bits en close_range() con CLOSE_RANGE_UNSHARE Se espera que copy_fd_bitmaps(new, old, count) copie los primeros bits count/BITS_PER_LONG de old->full_fds_bits[] y rellene el resto con ceros. Lo que hace es copiar suficientes palabras (BITS_TO_LONGS(count/BITS_PER_LONG)), luego memsets el resto. Eso funciona bien, *si* todos los bits más allá del punto de corte están limpios. De lo contrario, corremos el riesgo de basura de la última palabra que habíamos copiado. Para la mayoría de los llamadores, esto es cierto: expand_fdtable() tiene count igual a old->max_fds, por lo que no hay descriptores abiertos más allá de count, y mucho menos palabras completamente ocupadas en ->open_fds[], que es a lo que corresponden los bits en ->full_fds_bits[]. El otro llamador (dup_fd()) pasa sane_fdtable_size(old_fdt, max_fds), que es el múltiplo más pequeño de BITS_PER_LONG que cubre todos los descriptores abiertos por debajo de max_fds. En el caso común (copiar en fork()) max_fds es ~0U, por lo que todos los descriptores abiertos estarán por debajo de él y estamos bien, por las mismas razones por las que la llamada en expand_fdtable() es segura. Desafortunadamente, hay un caso en el que max_fds es menor que eso y en el que, de hecho, podríamos terminar con basura en ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) con * tabla de descriptores que se comparte actualmente * 'to' está por encima de la capacidad actual de la tabla de descriptores * 'from' está justo debajo de algún trozo de descriptores abiertos. En ese caso, terminamos con un comportamiento observablemente incorrecto, por ejemplo, generar un hijo con CLONE_FILES, obtener todos los descriptores en el rango 0..127 abiertos, luego close_range(64, ~0U, CLOSE_RANGE_UNSHARE) y ver que dup(0) termina con el descriptor #128, a pesar de que #64 no está abierta observablemente. La solución mínimamente invasiva sería lidiar con eso en dup_fd(). Si esto demuestra agregar una sobrecarga medible, podemos ir por ese camino, pero intentemos arreglar copy_fd_bitmaps() primero. * nuevo ayudante: bitmap_copy_and_expand(to, from, bits_to_copy, size). * hacer que copy_fd_bitmaps() tome el tamaño del mapa de bits en palabras, en lugar de bits; Su argumento 'count' es siempre un múltiplo de BITS_PER_LONG, por lo que no perdemos ninguna información y de esa manera podemos usar el mismo asistente para los tres mapas de bits: el compilador verá que count es un múltiplo de BITS_PER_LONG para los grandes, por lo que generará memcpy()+memset() simple. Se agregó el reproductor a tools/testing/selftests/core/close_range_test.c