Vulnerabilidades

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.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:ll_temac: platform_get_resource reemplazada por una función incorrecta La función platform_get_resource fue reemplazada por devm_platform_ioremap_resource_byname y se llama usando 0 como nombre. Esto eventualmente termina en platform_get_resource_byname en la pila de llamadas, donde genera un puntero null en strcmp. if (type == Resource_type(r) && !strcmp(r->name, name)) Debería haber sido reemplazado por devm_platform_ioremap_resource.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrigió bloqueo/desbordamiento insuficiente al realizar la transición a ODM4:1 [Por qué] En algunas circunstancias, deshabilitar un OPTC e intentar reclamar sus OPP para otro OPTC podría causar un bloqueo/desbordamiento insuficiente debido a que los OPP no se desconectan correctamente del OPTC deshabilitado. [Cómo] Asegúrese de que todos los OPP estén desasignados de un OPTC cuando se deshabilite.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige un error de puntero null de debugfs [POR QUÉ Y CÓMO] Verifique si la devolución de llamada get_subvp_en() existe antes de llamarla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rpmsg: virtio: Free driver_overridecuando rpmsg_remove() Free driver_override cuando rpmsg_remove(); de lo contrario, se producirá la siguiente pérdida de memoria: objeto sin referencia 0xffff0000d55d7080 (tamaño 128): comm "kworker/u8 :2", pid 56, santiamén 4294893188 (edad 214.272s) volcado hexadecimal (primeros 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso: [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320 [<000000002300d89b>] +0x44/ 0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driver_set_override+0xd0/0x164 [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170 0000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30 [<000000008bbf8fa2>] rpmsg_probe+0x2e0/ 0x3ec [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280 [<00000000443331cc>] very_probe+0xbc/0x2dc [<00000000391064b1>] __driver_probe_device+0x78/0xe0 [<00 000000a41c9a5b>] driver_probe_device+0xd8/0x160 [<000000009c3bd5df>] __device_attach_driver+0xb8/ 0x140 [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4 [<000000003b929a36>] __device_attach+0x9c/0x19c [<00000000a94e0ba8>] dispositivo_initial_probe+0x14/0x20 [<000 000003c999637>] bus_probe_device+0xa0/0xac

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tubería: despertar wr_wait después de configurar max_usage Confirmar c73be61cede5 ("tubería: Agregar soporte de cola de notificaciones generales") se introdujo una regresión que bloquearía las tuberías redimensionadas bajo ciertas condiciones. Ver el reproductor en [1]. La confirmación de cambio de tamaño del anillo de tubería se movió a una función diferente, lo que movió la activación de pipe->wr_wait antes de aumentar pipe->max_usage. Si una tubería estaba llena antes de que ocurriera el cambio de tamaño, la reactivación nunca activaría pipe_write. Configure @max_usage y @nr_accounted antes de despertar a los escritores si no se trata de una cola de vigilancia. [Christian Brauner : reescribir en la cuenta para las colas de visualización]