Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corregida la corrupción durante el cambio de tamaño en línea Observamos una corrupción durante el cambio de tamaño en línea de un sistema de archivos de más de 16 TiB con un tamaño de bloque de 4k. Al tener más de 2 ^ 32 bloques, mke2fs desactiva resize_inode de forma predeterminada. El problema se puede reproducir en un sistema de archivos más pequeño por conveniencia desactivando explícitamente resize_inode. Un cambio de tamaño en línea a través de un límite de 8 GiB (el tamaño de un grupo de metabloques en esta configuración) conduce a una corrupción: dev=/dev/ # debería ser >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # soltar caché de página para forzar la recarga del bloque desde el disco echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equivale a 8 GiB de los cuales 2^15 es el número de bloques por grupo de bloques y 2^6 es el número de grupos de bloques que forman un metagrupo de bloques. La última suma de comprobación puede ser diferente dependiendo de cómo esté distribuido el archivo en los bloques físicos. La corrupción real ocurre en el bloque físico 63*2^15 = 2064384, que sería la ubicación de la copia de seguridad del descriptor de bloque del grupo de metabloques. Durante el cambio de tamaño en línea, el sistema de archivos se convertirá a meta_bg comenzando en s_first_meta_bg, que en el ejemplo es 2, es decir, todos los grupos de bloques después de 16 GiB. Sin embargo, en ext4_flex_group_add podríamos agregar grupos de bloques que aún no forman parte del primer metagrupo de bloques. En el reproductor logramos esto restando el tamaño de un grupo de bloques completo desde el punto donde comenzaría el grupo de metabloques. Esto debe tenerse en cuenta al actualizar los descriptores del grupo de bloques de respaldo para que sigan el diseño que no es meta_bg. La solución es agregar una prueba de si el grupo a agregar ya forma parte del grupo de metabloques o no.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/sev: corregidas las referencias de variables dependientes de la posición en el código de inicio. El código de inicio temprano se ejecuta desde una asignación de memoria 1:1, que difiere de la asignación a la que se vinculó el código y/. o reubicado para correr. Esta última asignación aún no está activa en este momento, por lo que las referencias de símbolos que dependen de ella fallarán. Dado que el kernel principal está construido sin -fPIC, las referencias a símbolos generalmente se emiten como absolutas, por lo que cualquier referencia de este tipo que ocurra en el código de inicio temprano bloqueará el kernel. Si bien se intentó solucionar este problema en el código de inicio inicial de SEV/SME, forzando el direccionamiento relativo a RIP para ciertas variables globales de SEV/SME mediante un ensamblaje en línea (consulte snp_cpuid_get_table(), por ejemplo), el direccionamiento relativo a RIP debe ser omnipresente. aplicado para las variables globales SEV/SME cuando se accede a ellas antes de las correcciones de la tabla de páginas. __startup_64() ya maneja este problema para variables globales seleccionadas que no son SEV/SME usando fixup_pointer(), que ajusta el puntero en relación con un argumento `physaddr`. Para evitar tener que pasar este argumento `physaddr` entre todas las funciones que necesitan aplicar correcciones de puntero, introduzca una macro RIP_RELATIVE_REF() que genera una referencia relativa a RIP a una variable global determinada. Se utiliza cuando es necesario para forzar accesos relativos a RIP a variables globales. Para fines de backport, este parche no intenta limpiar otras apariciones de este patrón, que involucran inline asm o fixup_pointer(). Estos se abordarán más adelante. [bp: llámelo "rip_rel_ref" en todas partes, como otros códigos acortan la "referencia relativa a rIP" y hacen que el contenedor ASM sea __always_inline. ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/efistub: llame a los servicios de arranque en modo mixto en la pila del firmware. Normalmente, el código auxiliar de EFI llama a los servicios de arranque de EFI utilizando la pila que estaba activa cuando se ingresó el código auxiliar. Según la especificación UEFI, esta pila debe tener un tamaño mínimo de 128k; esto puede parecer grande, pero todo el procesamiento asíncrono y el manejo de eventos en EFI se ejecutan desde la misma pila, por lo que en la práctica se puede utilizar bastante espacio. En modo mixto, la situación es un poco diferente: el gestor de arranque llama al punto de entrada del código auxiliar EFI de 32 bits, que llama al punto de entrada de 32 bits del descompresor, donde se configura la pila de arranque, utilizando una asignación fija de 16k. Esta pila todavía está en uso cuando el código auxiliar EFI se inicia en modo de 64 bits, por lo que todas las llamadas al firmware EFI utilizarán la pila de arranque limitada del descompresor. Debido a la ubicación de la pila de arranque justo después del montón de arranque, cualquier desbordamiento de la pila pasa desapercibido. Sin embargo, la confirmación 5c4feadb0011983b ("x86/decompressor: Mover referencias de símbolos globales al código C") movió la definición del montón de arranque al código C, y ahora la pila de arranque se coloca justo en la base de BSS, donde cualquier desbordamiento dañará el final de la sección .data. Si bien sería posible solucionar este problema aumentando el tamaño de la pila de arranque, hacerlo afectaría a todos los sistemas x86, y los sistemas de modo mixto son una fracción pequeña (y cada vez menor) de la base instalada x86. En su lugar, registre el valor del puntero de la pila de firmware al ingresar desde el firmware de 32 bits y cambie a esta pila cada vez que se realice una llamada al servicio de arranque EFI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: marcar el gfn de destino de la instrucción atómica emulada como sucia Al emular un acceso atómico en nombre del invitado, marque el gfn de destino como sucio si se intenta realizar el CMPXCHG por KVM y no falla. Esto corrige un error por el cual KVM corrompe efectivamente la memoria del invitado durante la migración en vivo al escribir en la memoria del invitado sin informar al espacio de usuario que la página está sucia. Marcar la página como sucia se eliminó involuntariamente cuando el CMPXCHG emulado de KVM se convirtió para realizar un acceso de usuario. Antes de eso, KVM asignaba explícitamente la página invitada a la memoria del kernel y marcaba la página como sucia durante la fase de desasignación. Marque la página como sucia incluso si CMPXCHG falla, ya que los datos antiguos se vuelven a escribir en caso de fallo, es decir, la página aún está escrita. Se garantiza que el valor escrito será el mismo porque la operación es atómica, pero la ABI de KVM es que todas las escrituras se registran de forma sucia independientemente del valor escrito. Y lo que es más importante, eso es lo que hizo KVM antes de la confirmación del error. Felicitaciones enormes a las personas en la lista Cc (y a muchos otros), que hicieron todo el trabajo de clasificación y depuración. confirmación base: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm snapshot: corregido el bloqueo en dm_exception_table_exit Se informó un bloqueo cuando salimos de un snapshot con muchas excepciones. Solucione este problema agregando "cond_resched" al bucle que libera las excepciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la ejecución en read_extent_buffer_pages() Hay informes de tree-checker que detecta nodos corruptos, sin ningún patrón obvio por lo que posiblemente se sobrescriba en la memoria. Después de un poco de depuración, resulta que hay una ejecución cuando al leer un búfer de extensión se puede perder el estado de actualización. Para evitar lecturas simultáneas para el mismo búfer de extensión, read_extent_buffer_pages() realiza estas comprobaciones: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) ir a listo; En este punto, parece seguro iniciar la operación de lectura real. Una vez que se completa, end_bbio_meta_read() hace /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normalmente, esto es suficiente para garantizar que solo se realice una lectura y que todos los demás llamantes esperen a que finalice antes de regresar. Desafortunadamente, hay un entrelazado racial: Hilo A | Hilo B | Rosca C ---------+----------+----------------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) Cuando esto sucede, el hilo B inicia una lectura innecesaria. Peor aún, el subproceso C verá la ACTUALIZACIÓN configurada y regresará inmediatamente, mientras la lectura del subproceso B aún está en progreso. Esta ejecución podría dar como resultado errores del comprobador de árbol como este, ya que el búfer de extensión se modifica simultáneamente: BTRFS crítico (dispositivo dm-0): nodo dañado, raíz=256 bloque=8550954455682405139 el propietario no coincide, tiene 11858205567642294356 expect [256, 18446744073709551360] Arreglarlo probando UPTODATE nuevamente después de configurar el bit de LECTURA y, si se ha configurado, omita la lectura innecesaria. [actualización menor del registro de cambios]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: evita fallos al deshabilitar la transmisión [Por qué] Al deshabilitar el codificador de transmisión se invoca una función que ya no existe. [Cómo] Compruebe si la declaración de función es NULL al desactivar el codificador de flujo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi: arreglado el pánico en el kernel kdump. Compruebe si get_next_variable() es realmente un puntero válido antes de llamarlo. En el kernel kdump, este método está configurado en NULL, lo que provoca pánico durante el arranque del kernel kexec-ed. Probado con firmware QEMU y OVMF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: mantenga xfd_state sincronizado con MSR_IA32_XFD Confirme 672365477ae8 ("x86/fpu: actualice el estado de XFD cuando sea necesario") y confirme 8bf26758ca96 ("x86/fpu: agregue el estado de XFD a fpstate") introdujo una variable xfd_state por CPU para mantener el valor MSR_IA32_XFD en caché, a fin de evitar escrituras innecesarias en el MSR. En la conexión en caliente de la CPU, MSR_IA32_XFD se restablece a init_fpstate.xfd, lo que elimina cualquier estado obsoleto. Pero el valor xfd almacenado en caché por CPU no se restablece, lo que los desincroniza. Como consecuencia, un xfd_update_state() posterior podría no actualizar el MSR, lo que a su vez puede provocar que XRSTOR genere un #NM en el espacio del kernel, lo que bloquea el kernel. Para solucionar este problema, introduzca xfd_set_state() para escribir xfd_state junto con MSR_IA32_XFD y utilícelo en todos los lugares que configuren MSR_IA32_XFD.

Una vulnerabilidad de carga de archivos arbitrarios en el componente /include/file.php de lylme_spage v1.9.5 permite a los atacantes ejecutar código arbitrario cargando un archivo manipulado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige el punto muerto al leer mqd desde debugfs Una copia de seguridad de disco errónea en mi escritorio entró en debugfs y desencadenó el siguiente escenario de punto muerto en los archivos amdgpu debugfs. La máquina también se reinicia inmediatamente después de imprimir esas líneas (aunque no pude reproducir esa parte cuando leí a mano): [ 1318.016074][ T1082] =============== ======================================= [ 1318.016607][ T1082] ADVERTENCIA: posible bloqueo circular dependencia detectada [ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 No contaminado [ 1318.017598][ T1082] ----------------------- ------------------------------- [ 1318.018096][ T1082] tar/1082 está intentando adquirir el bloqueo: [ 1318.018585][ T1082] ffff98c44175d6a0 (&mm->mmap_lock){++++}-{3:3}, en: __might_fault+0x40/0x80 [ 1318.019084][ T1082] [ 1318.019084][ T1082] pero la tarea ya mantiene el bloqueo: [ 1318.020052 ][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, en: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.020607][ T1082] [ 1318.020607][ T1082] el bloqueo ya depende del nuevo cerrar con llave. [ 1318.020607][ T1082] [ 1318.022081][ T1082] [ 1318.022081][ T1082] la cadena de dependencia existente (en orden inverso) es: [ 1318.023083][ T1082] [ 1318.023083][ T1082] -> #2 (reservation_ww_ clase_mutex){+ .+.}-{3:3}: [ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0 [ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90 [ 1318.025161][ T1082] dep+0x18a/0x330 [ 1318.025683 ][ T1082] do_one_initcall+0x6a/0x350 [ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.026728][ T1082] kernel_init+0x15/0x1a0 [ 1318.027242][ T1082] from_fork+0x2c/0x40 [ 1318.027759][ T1082] ret_from_fork_asm+ 0x11/0x20 [ 1318.028281][ T1082] [ 1318.028281][ T1082] -> #1 (reservation_ww_class_acquire){+.+.}-{0:0}: [ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330 [ 1 318.029790][ T1082] do_one_initcall+0x6a/0x350 [ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.030722][ T1082] kernel_init+0x15/0x1a0 [ 1318.031168][ T1082] bifurcación+0x2c/0x40 [ 1318.031598][ T1082] ret_from_fork_asm+0x11/ 0x20 [ 1318.032011][ T1082] [ 1318.032011][ T1082] -> #0 (&mm->mmap_lock){++++}-{3:3}: [ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680 [ 1318.033141 ] [ T1082] lock_acquire+0xcd/0x2c0 [ 1318.033487][ T1082] __might_fault+0x58/0x80 [ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu] [ 1318.03418 1][T1082] lectura_proxy_completa+0x55/0x80 [1318.034487][T1082] vfs_read+0xa7/0x360 [ 1318.034788][ T1082] ksys_read+0x70/0xf0 [ 1318.035085][ T1082] do_syscall_64+0x94/0x180 [ 1318.035375][ T1082] wframe+0x46/0x4e [ 1318.035664][ T1082] [ 1318.035664][ T1082] Otra información que podría ayudarnos a depurar esto: [1318.035664] [T1082] [1318.036487] [T1082] La cadena existe de: [1318.036487] [T1082] & mm-> mmap_lock-> reservation_ww_class_acquire-> reservación_www_mutex. ] [ 1318.037310][T1082] Posible escenario de bloqueo inseguro: [ 1318.037310][ T1082] [ 1318.037838][ T1082] CPU0 CPU1 [ 1318.038101][ T1082] ---- ---- [ 1318.038350][ T1082] _class_mutex); [ 1318.038590][ T1082] bloqueo(reservation_ww_class_acquire); [ 1318.038839][ T1082] bloqueo(reservation_ww_class_mutex); [ 1318.039083][ T1082] rlock(&mm->mmap_lock); [ 1318.039328][ T1082] [ 1318.039328][ T1082] *** DEADLOCK *** [ 1318.039328][ T1082] [ 1318.040029][ T1082] 1 bloqueo retenido por tar/1082: [ 1318.040259][ T1082] #0: ffff98c4c13f55f8 ( reserve_ww_class_mutex){+.+.}-{3:3}, en: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.040560][ T1082] [ 1318.040560][ T1082] seguimiento de pila: [ ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: cachestat: corrige dos errores de shmem Cuando cachestat en shmem se ejecuta con intercambio e invalidación, hay dos errores posibles: 1) Un error de intercambio puede haber resultado en una entrada de intercambio envenenada en la matriz x del inodo shmem. Llamar a get_shadow_from_swap_cache() dará como resultado un acceso fuera de los límites a swapper_spaces[]. Valide la entrada con non_swap_entry() antes de continuar. 2) Cuando encontramos una entrada de intercambio válida en el inodo de shmem, es posible que la entrada oculta en el caché de intercambio aún no exista: el intercambio de E/S aún está en progreso y estamos antes de __remove_mapping; swapin, invalidación o swapoff han eliminado la sombra de swapcache después de que vimos la entrada de intercambio shmem. Esto enviará un NULL aworkingset_test_recent(). Este último opera exclusivamente con bits de puntero, por lo que no fallará (el nodo 0, el ID de memcg 0, la marca de tiempo de desalojo 0, etc. son todas entradas válidas), pero es una prueba falsa. En teoría, eso podría resultar en un recuento falso de "desalojados recientemente". Un falso positivo así no sería el fin del mundo. Pero para mayor claridad del código y solidez (futura), sea explícito sobre este caso. Libere get_shadow_from_swap_cache() y devuelva NULL.