Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: Solo permitir que act_ct se vincule a qdiscs clsact/de entrada y bloques compartidos<br /> <br /> Como Paolo dijo anteriormente [1]:<br /> <br /> &amp;#39;Desde el commit culpado a continuación, classify puede devolver TC_ACT_CONSUMED mientras el skb actual está siendo retenido por el motor de desfragmentación. Según lo informado por GangMin Kim, si dicho paquete es uno que puede causar un UaF cuando el motor de desfragmentación más tarde intente tocar de nuevo dicho paquete.&amp;#39;<br /> <br /> act_ct nunca estuvo destinado a ser usado en la ruta de salida, sin embargo, algunos usuarios lo están adjuntando a la salida hoy [2]. Intentando llegar a un punto intermedio, notamos que, mientras que la mayoría de los qdiscs no están manejando TC_ACT_CONSUMED, los qdiscs clsact/de entrada sí lo están. Con eso en mente, abordamos el problema permitiendo solo que act_ct se vincule a qdiscs clsact/de entrada y bloques compartidos. De esa manera, todavía es posible adjuntar act_ct a la salida (aunque solo con clsact).<br /> <br /> [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/<br /> [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Revertir &amp;#39;drm/amd: Comprobar si ASPM está habilitado desde el subsistema PCIe&amp;#39;<br /> <br /> Esto revierte el commit 7294863a6f01248d72b61d38478978d638641bee.<br /> <br /> Este commit fue aplicado erróneamente de nuevo después del commit 0ab5d711ec74<br /> (&amp;#39;drm/amd: Refactorizar amdgpu_aspm para ser evaluado por dispositivo&amp;#39;)<br /> lo eliminó, lo que llevó a fallos muy difíciles de depurar, cuando se usaba con un sistema con dos GPU AMD de las cuales solo una soporta ASPM.<br /> <br /> (seleccionado de forma selectiva del commit 97a9689300eb2b393ba5efc17c8e5db835917080)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: corrección para realizar una comprobación de coherencia en el pie de página del nodo en {read,write}_end_io<br /> <br /> -----------[ cut here ]------------<br /> BUG del kernel en fs/f2fs/data.c:358!<br /> Traza de llamadas:<br /> <br /> blk_update_request+0x5eb/0xe70 block/blk-mq.c:987<br /> blk_mq_end_request+0x3e/0x70 block/blk-mq.c:1149<br /> blk_complete_reqs block/blk-mq.c:1224 [inline]<br /> blk_done_softirq+0x107/0x160 block/blk-mq.c:1229<br /> handle_softirqs+0x283/0x870 kernel/softirq.c:579<br /> __do_softirq kernel/softirq.c:613 [inline]<br /> invoke_softirq kernel/softirq.c:453 [inline]<br /> __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680<br /> irq_exit_rcu+0x9/0x30 kernel/softirq.c:696<br /> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1050 [inline]<br /> sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1050<br /> <br /> <br /> En f2fs_write_end_io(), se detecta una inconsistencia entre el índice de la página de nodo (nid) y footer.nid de la página de nodo.<br /> <br /> Si el pie de página de la página de nodo está corrupto en una imagen sometida a fuzzing, entonces cargamos la página de nodo corrupta con un método asíncrono, p. ej., f2fs_ra_node_pages() o f2fs_ra_node_page(), donde no realizaremos una comprobación de coherencia en el pie de página del nodo; una vez que la página de nodo se vuelve sucia, encontraremos este error después de la escritura de vuelta de la página de nodo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fbdev: rivafb: corrige error de división en nv3_arb()<br /> <br /> Un programa de espacio de usuario puede activar el código de arbitraje RIVA NV3 llamando al ioctl FBIOPUT_VSCREENINFO en /dev/fb*. Al hacerlo, el controlador recalcula los parámetros de arbitraje FIFO en nv3_arb(), usando state-&amp;gt;mclk_khz (derivado del PRAMDAC MCLK PLL) como divisor sin validarlo primero.<br /> <br /> En una configuración normal, state-&amp;gt;mclk_khz es proporcionado por el hardware real y no es cero. Sin embargo, un atacante puede construir un dispositivo malicioso o mal configurado (p. ej., un dispositivo PCI manipulado/emulado) que expone una configuración PLL falsa, haciendo que state-&amp;gt;mclk_khz se vuelva cero. Una vez que nv3_get_param() llama a nv3_arb(), la división por state-&amp;gt;mclk_khz en el cálculo de gns causa un error de división y bloquea el kernel.<br /> <br /> Solucione esto verificando si state-&amp;gt;mclk_khz es cero y saliendo antes de realizar la división.<br /> <br /> El siguiente registro lo revela:<br /> <br /> rivafb: estableciendo la resolución Y virtual a 2184<br /> error de división: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 0 PID: 2187 Comm: syz-executor.0 No contaminado 5.18.0-rc1+ #1<br /> Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline]<br /> RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546<br /> Traza de llamada:<br /> nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603<br /> nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline]<br /> CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246<br /> riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779<br /> rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196<br /> fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033<br /> do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109<br /> fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188<br /> __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: corrige el problema de inconsistencia del flag IS_CHECKPOINTED causado por escrituras concurrentes de commit atómico y checkpoint<br /> <br /> Durante las pruebas SPO, al montar F2FS, se devolvió un error -EINVAL desde<br /> f2fs_recover_inode_page. El problema ocurrió bajo el siguiente escenario<br /> <br /> Hilo A Hilo B<br /> f2fs_ioc_commit_atomic_write<br /> - f2fs_do_sync_file // atómico = true<br /> - f2fs_fsync_node_pages<br /> : last_folio = inode folio<br /> : schedule before folio_lock(last_folio) f2fs_write_checkpoint<br /> - block_operations// writeback last_folio<br /> - schedule before f2fs_flush_nat_entries<br /> : set_fsync_mark(last_folio, 1)<br /> : set_dentry_mark(last_folio, 1)<br /> : folio_mark_dirty(last_folio)<br /> - __write_node_folio(last_folio)<br /> : f2fs_down_read(&amp;amp;sbi-&amp;gt;node_write)//bloquea<br /> - f2fs_flush_nat_entries<br /> : {struct nat_entry}-&amp;gt;flag |= BIT(IS_CHECKPOINTED)<br /> - unblock_operations<br /> : f2fs_up_write(&amp;amp;sbi-&amp;gt;node_write)<br /> f2fs_write_checkpoint//retorna<br /> : f2fs_do_write_node_page()<br /> f2fs_ioc_commit_atomic_write//retorna<br /> SPO<br /> <br /> El Hilo A llama a f2fs_need_dentry_mark(sbi, ino), y el last_folio ya ha<br /> sido escrito una vez. Sin embargo, el {struct nat_entry}-&amp;gt;flag no tenía<br /> el IS_CHECKPOINTED establecido, causando que set_dentry_mark(last_folio, 1) y<br /> se escriba last_folio de nuevo después de que el Hilo B termine f2fs_write_checkpoint.<br /> <br /> Después de SPO y el reinicio, se detectó que {struct node_info}-&amp;gt;blk_addr<br /> no era NULL_ADDR porque el Hilo B escribió exitosamente el checkpoint.<br /> <br /> Este problema solo ocurre en escenarios de escritura atómica. Para operaciones<br /> fsync de archivos regulares, el folio debe estar sucio. Si<br /> block_operations-&amp;gt;f2fs_sync_node_pages envía exitosamente la escritura del folio,<br /> esta ruta no se ejecutará. De lo contrario, f2fs_write_checkpoint deberá esperar<br /> a que se complete el envío de la escritura del folio, ya que<br /> sbi-&amp;gt;nr_pages[F2FS_DIRTY_NODES] &amp;gt; 0. Por lo tanto, la situación en la que<br /> f2fs_need_dentry_mark verifica que el {struct nat_entry}-&amp;gt;flag sin el flag<br /> IS_CHECKPOINTED, pero la escritura del folio ya ha sido enviada, no ocurrirá.<br /> <br /> Por lo tanto, para fsync de archivos atómicos, sbi-&amp;gt;node_write debe adquirirse<br /> a través de __write_node_folio para asegurar que el flag IS_CHECKPOINTED<br /> indique correctamente que la escritura del checkpoint ha sido completada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> apparmor: corrección de que un usuario local sin privilegios puede realizar gestión de políticas privilegiada<br /> <br /> Un usuario local sin privilegios puede cargar, reemplazar y eliminar perfiles abriendo las interfaces de apparmorfs, a través de un ataque de adjunto confundido, pasando el descriptor de archivo (fd) abierto a un proceso privilegiado y haciendo que el proceso privilegiado escriba en la interfaz.<br /> <br /> Esto requiere un objetivo privilegiado que pueda ser manipulado para realizar la escritura en nombre del proceso sin privilegios, pero una vez que se logra dicho acceso, es posible una gestión completa de políticas y todas las posibles implicaciones que esto conlleva: eliminación del confinamiento, DoS del sistema o de las aplicaciones objetivo denegando toda ejecución, eludiendo la restricción del espacio de nombres de usuario sin privilegios, hasta la explotación de errores del kernel para una escalada de privilegios local.<br /> <br /> La interfaz de gestión de políticas no puede tener sus permisos simplemente cambiados de 0666 a 0600 porque los procesos que no son root necesitan poder cargar políticas en diferentes espacios de nombres de políticas.<br /> <br /> En su lugar, asegúrese de que la tarea que escribe en la interfaz tenga privilegios que sean un subconjunto de la tarea que abrió la interfaz. Esto ya se hace a través de políticas para procesos confinados, pero los no confinados pueden delegar acceso al descriptor de archivo (fd) abierto, eludiendo la verificación de política habitual.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> apparmor: validar que los estados iniciales de DFA están dentro de los límites en unpack_pdb<br /> <br /> Los estados iniciales se leen de datos no confiables y se usan como índices en las tablas de estados de DFA. La llamada a la función aa_dfa_next() en unpack_pdb() accederá a dfa-&amp;gt;tables[YYTD_ID_BASE][start], y si el estado inicial excede el número de estados en el DFA, esto resulta en una lectura fuera de límites.<br /> <br /> ==================================================================<br /> ERROR: KASAN: slab-out-of-bounds en aa_dfa_next+0x2a1/0x360<br /> Lectura de tamaño 4 en la dirección ffff88811956fb90 por la tarea su/1097<br /> ...<br /> <br /> Rechazar políticas con estados iniciales fuera de límites durante el desempaquetado para prevenir el problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: liquidio: Inicializar el puntero netdev antes de la configuración de la cola<br /> <br /> En setup_nic_devices(), el netdev se asigna usando alloc_etherdev_mq(). Sin embargo, el puntero a esta estructura se almacena en oct-&amp;gt;props[i].netdev solo después de las llamadas a netif_set_real_num_rx_queues() y netif_set_real_num_tx_queues().<br /> <br /> Si alguna de estas funciones falla, setup_nic_devices() devuelve un error sin liberar el netdev asignado. Dado que oct-&amp;gt;props[i].netdev sigue siendo NULL en este punto, la función de limpieza liquidio_destroy_nic_device() no logrará encontrar y liberar el netdev, lo que resultará en una fuga de memoria.<br /> <br /> Corrija esto inicializando oct-&amp;gt;props[i].netdev antes de llamar a las funciones de configuración de cola. Esto asegura que el netdev sea correctamente accesible para la limpieza en caso de errores.<br /> <br /> Probado solo en compilación. Problema encontrado usando una herramienta prototipo de análisis estático y revisión de código.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> io_uring/rw: liberar iovec potencialmente asignado en caso de fallo al colocar en la caché<br /> <br /> Si una solicitud de lectura/escritura pasa por io_req_rw_cleanup() y tiene un iovec asignado adjunto y falla al colocarlo en la rw_cache, entonces puede terminar con un puntero iovec no contabilizado. Hacer que io_rw_recycle() devuelva si recicló la solicitud o no, y usar eso para determinar si liberar un iovec potencial o no.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> regmap: maple: liberar entrada en caso de fallo de mas_store_gfp()<br /> <br /> regcache_maple_write() asigna un nuevo bloque (&amp;#39;entrada&amp;#39;) para fusionar rangos adyacentes y luego lo almacena con mas_store_gfp().<br /> Cuando mas_store_gfp() falla, la nueva &amp;#39;entrada&amp;#39; permanece asignada y nunca es liberada, provocando una fuga de memoria.<br /> <br /> Liberar &amp;#39;entrada&amp;#39; en la ruta de fallo; en caso de éxito, continuar liberando los bloques vecinos reemplazados (&amp;#39;inferior&amp;#39;, &amp;#39;superior&amp;#39;).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvme-fc: liberar el conjunto de etiquetas de administración si la inicialización falla<br /> <br /> nvme_fabrics crea un controlador NVMe/FC en la siguiente ruta:<br /> <br /> nvmf_dev_write()<br /> -&amp;gt; nvmf_create_ctrl()<br /> -&amp;gt; nvme_fc_create_ctrl()<br /> -&amp;gt; nvme_fc_init_ctrl()<br /> <br /> nvme_fc_init_ctrl() asigna los recursos blk-mq de administración justo después de que nvme_add_ctrl() tenga éxito. Si alguno de los pasos subsiguientes falla (cambiar el estado del controlador, programar el trabajo de conexión, etc.), saltamos a la ruta fail_ctrl, que desmantela las referencias del controlador pero nunca libera la cola/conjunto de etiquetas de administración. Las asignaciones blk-mq filtradas coinciden con el informe kmemleak visto durante blktests nvme/fc.<br /> <br /> Verificar ctrl-&amp;gt;ctrl.admin_tagset en la ruta fail_ctrl y llamar a nvme_remove_admin_tag_set() cuando esté establecido para que todas las asignaciones de la cola de administración sean recuperadas cada vez que la configuración del controlador se aborte.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gve: Corrección de la corrupción del informe de estadísticas al cambiar el recuento de colas<br /> <br /> El controlador y la NIC comparten una región en memoria para el informe de estadísticas.<br /> La NIC calcula su desplazamiento en esta región basándose en el tamaño total<br /> de la región de estadísticas y el tamaño de las estadísticas de la NIC.<br /> <br /> Cuando se cambia el número de colas, la región de estadísticas del controlador se<br /> redimensiona. Si el recuento de colas se incrementa, la NIC puede escribir más allá<br /> del final de la región de estadísticas asignada, causando corrupción de memoria.<br /> Si el recuento de colas se disminuye, hay una brecha entre las estadísticas del controlador<br /> y de la NIC, lo que lleva a un informe de estadísticas incorrecto.<br /> <br /> Este cambio soluciona el problema asignando la región de estadísticas con el tamaño<br /> máximo, y el cálculo del desplazamiento para las estadísticas de la NIC se cambia para que<br /> coincida con el cálculo de la NIC.