Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> sched/deadline: solo establecer free_cpus para runqueues en línea<br /> <br /> El commit 16b269436b72 (&amp;#39;sched/deadline: Modificar cpudl::free_cpus para reflejar rd-&amp;gt;online&amp;#39;) introdujo las funciones cpudl_set/clear_freecpu para permitir que la máscara cpu_dl::free_cpus fuera manipulada por las devoluciones de llamada rq_on/offline de la clase de planificador de plazo para que la máscara también reflejara este estado.<br /> <br /> El commit 9659e1eeee28 (&amp;#39;sched/deadline: Eliminar cpu_active_mask de cpudl_find()&amp;#39;) eliminó la comprobación de la cpu_active_mask para ahorrar algo de procesamiento bajo la premisa de que la máscara cpudl::free_cpus ya reflejaba el estado en línea del runqueue.<br /> <br /> Desafortunadamente, hay casos en los que es posible que la función cpudl_clear establezca el bit free_cpus para una CPU cuando el runqueue de plazo está fuera de línea. Cuando esto ocurre mientras una CPU está conectada al dominio raíz predeterminado, el indicador puede retener el estado incorrecto después de que la CPU haya sido desconectada. Más tarde, una CPU diferente que está en transición a través del dominio raíz predeterminado puede empujar una tarea de plazo a la CPU apagada cuando cpudl_find ve que su bit free_cpus está establecido. Si esto sucede, la tarea no tendrá la oportunidad de ejecutarse.<br /> <br /> Un ejemplo se describe aquí:<br /> https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com<br /> <br /> Otro ocurre cuando la última tarea de plazo es migrada de una CPU que tiene un runqueue fuera de línea. El miembro dequeue_task de la clase de planificador de plazo eventualmente llamará a cpudl_clear y establecerá el bit free_cpus para la CPU.<br /> <br /> Este commit modifica la función cpudl_clear para que sea consciente del estado en línea del runqueue de plazo para que la máscara free_cpus pueda ser actualizada apropiadamente.<br /> <br /> Ya no es necesario gestionar la máscara fuera de las funciones cpudl_set/clear, por lo que las funciones cpudl_set/clear_freecpu son eliminadas. Además, dado que la máscara free_cpus ahora solo se actualiza bajo el bloqueo cpudl, el código fue cambiado para usar las funciones no atómicas __cpumask.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> usb: phy: fsl-usb: Corrección de uso después de liberación en trabajo retrasado durante la eliminación del dispositivo<br /> <br /> El elemento de trabajo retrasado otg_event se inicializa en fsl_otg_conf() y se programa bajo dos condiciones:<br /> 1. Cuando un controlador de host se enlaza al controlador OTG.<br /> 2. Cuando el estado del pin ID USB cambia (inserción/extracción de cable).<br /> <br /> Una condición de carrera ocurre cuando el dispositivo es eliminado a través de fsl_otg_remove(): la instancia fsl_otg puede ser liberada mientras el trabajo retrasado aún está pendiente o ejecutándose. Esto lleva a un uso después de liberación cuando la función de trabajo fsl_otg_event() accede a la memoria ya liberada.<br /> <br /> El escenario problemático:<br /> <br /> (hilo de desvinculación) | (trabajo retrasado)<br /> fsl_otg_remove() |<br /> kfree(fsl_otg_dev) //FREE| fsl_otg_event()<br /> | og = container_of(...) //USE<br /> | og-&amp;gt; //USE<br /> <br /> Solucione esto llamando a disable_delayed_work_sync() en fsl_otg_remove() antes de desasignar la estructura fsl_otg. Esto asegura que el trabajo retrasado sea cancelado correctamente y complete su ejecución antes de la desasignación de memoria.<br /> <br /> Este error fue identificado a través de análisis estático.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: target: Restablecer el puntero t_task_cdb en caso de error<br /> <br /> Si la asignación de cmd-&amp;gt;t_task_cdb falla, permanece NULL pero luego es desreferenciado en la ruta de &amp;#39;error&amp;#39;.<br /> <br /> En caso de error, restablecer el valor NULL de t_task_cdb para que apunte al búfer predeterminado de tamaño fijo.<br /> <br /> Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> hfsplus: Verificar el modo del inodo al cargar desde el disco<br /> <br /> syzbot está informando que los bits S_IFMT de inode-&amp;gt;i_mode pueden volverse inválidos cuando los bits S_IFMT del campo &amp;#39;mode&amp;#39; de 16 bits cargado desde el disco están corruptos.<br /> <br /> Según [1], el campo de permisos fue tratado como reservado en Mac OS 8 y 9. Según [2], el campo reservado fue inicializado explícitamente con 0, y ese campo debe permanecer en 0 mientras esté reservado. Por lo tanto, cuando el campo &amp;#39;mode&amp;#39; no es 0 (es decir, ya no está reservado), el archivo debe ser S_IFDIR si dir == 1, y el archivo debe ser uno de S_IFREG/S_IFLNK/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK si dir == 0.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> inet: frags: vaciar skbs pendientes en fqdir_pre_exit()<br /> <br /> Hemos estado viendo interbloqueos ocasionales en pernet_ops_rwsem desde septiembre en NIPA. La tarea atascada era usualmente modprobe (a menudo cargando un controlador como ipvlan), intentando tomar el bloqueo como un Escritor. lockdep no rastrea lectores para rwsems por lo que la lectura no era obvia de los informes.<br /> <br /> En una inspección más cercana, el Lector que mantenía el bloqueo era conntrack haciendo un bucle para siempre en nf_conntrack_cleanup_net_list(). Basado en la experiencia pasada con fallos ocasionales de NIPA, revisé las pruebas que se ejecutan antes del fallo y noté que el fallo sigue a ip_defrag.sh. Una bandera roja inmediata. Revisar a fondo las colas de (des)fragmentación revela skbs que permanecen, manteniendo referencias de conntrack.<br /> <br /> El problema es que, dado que conntrack depende de nf_defrag_ipv6, nf_defrag_ipv6 se cargará primero. Dado que nf_defrag_ipv6 se carga primero, sus hooks de salida de netns se ejecutan _después_ del hook de salida de netns de conntrack.<br /> <br /> Vaciar todos los SKBs de la cola de fragmentos durante fqdir_pre_exit() para liberar referencias de conntrack antes de que se ejecute la limpieza de conntrack. También vaciar las colas en los manejadores de expiración del temporizador cuando descubren que fqdir-&amp;gt;dead está establecido, en caso de que un paquete se cuele mientras estamos ejecutando el vaciado de pre_exit.<br /> <br /> El commit bajo Fixes no es exactamente el culpable, pero creo que anteriormente el disparo del temporizador eventualmente desbloquearía el conntrack en bucle.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: corrige el valor de retorno de f2fs_recover_fsync_data()<br /> <br /> Con los siguientes scripts, se activará un pánico en f2fs:<br /> <br /> mkfs.f2fs -f /dev/vdd<br /> mount /dev/vdd /mnt/f2fs<br /> touch /mnt/f2fs/foo<br /> sync<br /> echo 111 &amp;gt;&amp;gt; /mnt/f2fs/foo<br /> f2fs_io fsync /mnt/f2fs/foo<br /> f2fs_io shutdown 2 /mnt/f2fs<br /> umount /mnt/f2fs<br /> mount -o ro,norecovery /dev/vdd /mnt/f2fs<br /> or<br /> mount -o ro,disable_roll_forward /dev/vdd /mnt/f2fs<br /> <br /> F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0<br /> F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361f<br /> F2FS-fs (vdd): Stopped filesystem due to reason: 0<br /> F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1<br /> Filesystem f2fs get_tree() didn&amp;#39;t set fc-&amp;gt;root, returned 1<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/super.c:1761!<br /> Oops: invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:vfs_get_tree.cold+0x18/0x1a<br /> Call Trace:<br /> <br /> fc_mount+0x13/0xa0<br /> path_mount+0x34e/0xc50<br /> __x64_sys_mount+0x121/0x150<br /> do_syscall_64+0x84/0x800<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fa6cc126cfe<br /> <br /> La causa raíz es que omitimos manejar el número de error devuelto por f2fs_recover_fsync_data() al montar la imagen con la opción de montaje ro,norecovery o ro,disable_roll_forward, lo que resulta en la devolución de un número de error positivo a vfs_get_tree(), se corrige.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bnxt_en: Corrección de la ruta XDP_TX<br /> <br /> Para la acción XDP_TX en bnxt_rx_xdp(), la limpieza de los indicadores de evento no es correcta. __bnxt_poll_work() -&amp;gt; bnxt_rx_pkt() -&amp;gt; bnxt_rx_xdp() puede estar en un bucle dentro de NAPI y algunos indicadores de evento pueden haber sido establecidos en iteraciones anteriores. En particular, si BNXT_TX_EVENT se establece antes indicando que algunos paquetes XDP_TX están listos y pendientes, se borrará si es una acción XDP_TX de nuevo. Normalmente, estableceremos BNXT_TX_EVENT de nuevo cuando llamemos con éxito a __bnxt_xmit_xdp(). Pero si el anillo TX no tiene más espacio, el indicador no se establecerá. Esto hará que el productor TX se adelante, pero el controlador no activará el TX doorbell.<br /> <br /> Para XDP_TX de múltiples búferes, no es necesario borrar los indicadores de evento y establecer BNXT_AGG_EVENT. El indicador BNXT_AGG_EVENT debería haberse establecido antes en bnxt_rx_pkt().<br /> <br /> El síntoma visible de esto es que el anillo RX asociado con el anillo TX XDP eventualmente quedará vacío y todos los paquetes se descartarán. Porque esta condición hará que el controlador no rellene el anillo RX al ver que el anillo TX tiene paquetes XDP_TX pendientes indefinidamente.<br /> <br /> La solución es borrar BNXT_RX_EVENT solo cuando hayamos llamado con éxito a __bnxt_xmit_xdp().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ocfs2: corrige un BUG del kernel en ocfs2_find_victim_chain<br /> <br /> syzbot informó un BUG del kernel en ocfs2_find_victim_chain() porque el campo &amp;#39;cl_next_free_rec&amp;#39; de la lista de cadenas de asignación (siguiente ranura libre en la lista de cadenas) es 0, lo que activa la condición BUG_ON(!cl-&amp;gt;cl_next_free_rec) en ocfs2_find_victim_chain() y provoca un pánico en el kernel.<br /> <br /> Para solucionar esto, se introduce una condición &amp;#39;if&amp;#39; en ocfs2_claim_suballoc_bits(), justo antes de llamar a ocfs2_find_victim_chain(), ejecutándose el bloque de código dentro de ella cuando cualquiera de las siguientes condiciones es verdadera:<br /> <br /> 1. &amp;#39;cl_next_free_rec&amp;#39; es igual a 0, lo que indica que no hay cadenas libres en la lista de cadenas de asignación<br /> 2. &amp;#39;cl_next_free_rec&amp;#39; es mayor que &amp;#39;cl_count&amp;#39; (el número total de cadenas en la lista de cadenas de asignación)<br /> <br /> Que cualquiera de ellas sea verdadera es indicativo del hecho de que no quedan cadenas para su uso.<br /> <br /> Esto se aborda utilizando ocfs2_error(), que imprime el registro de errores para fines de depuración, en lugar de provocar un pánico en el kernel.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: corrección para evitar actualizar el contexto de compresión durante la escritura de retorno<br /> <br /> Bai, Shuangpeng informó de un error como se detalla a continuación:<br /> <br /> Oops: divide error: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857<br /> Call Trace:<br /> <br /> f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline]<br /> __f2fs_write_data_pages fs/f2fs/data.c:3290 [inline]<br /> f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317<br /> do_writepages+0x38e/0x640 mm/page-writeback.c:2634<br /> filemap_fdatawrite_wbc mm/filemap.c:386 [inline]<br /> __filemap_fdatawrite_range mm/filemap.c:419 [inline]<br /> file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794<br /> f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294<br /> generic_write_sync include/linux/fs.h:3043 [inline]<br /> f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x7e9/0xe00 fs/read_write.c:686<br /> ksys_write+0x19d/0x2d0 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> El error se activó con la siguiente condición de carrera:<br /> <br /> fsync setattr ioctl<br /> - f2fs_do_sync_file<br /> - file_write_and_wait_range<br /> - f2fs_write_cache_pages<br /> : el inodo no está comprimido<br /> : cc.cluster_size =<br /> F2FS_I(inode)-&amp;gt;i_cluster_size = 0<br /> - tag_pages_for_writeback<br /> - f2fs_setattr<br /> - truncate_setsize<br /> - f2fs_truncate<br /> - f2fs_fileattr_set<br /> - f2fs_setflags_common<br /> - set_compress_context<br /> : F2FS_I(inode)-&amp;gt;i_cluster_size = 4<br /> : set_inode_flag(inode, FI_COMPRESSED_FILE)<br /> - f2fs_compressed_file<br /> : return true<br /> - f2fs_all_cluster_page_ready<br /> : "pgidx % cc-&amp;gt;cluster_size" desencadena el problema de división por 0<br /> <br /> Realicemos los siguientes cambios para solucionar este problema:<br /> - introducir una nueva variable de tipo atómico .writeback en la estructura f2fs_inode_info para rastrear el número de hilos que llaman a f2fs_write_cache_pages().<br /> - usar el bloqueo .i_sem para proteger la actualización de .writeback.<br /> - verificar .writeback antes de actualizar el contexto de compresión en f2fs_setflags_common() para evitar una condición de carrera con -&amp;gt;writepages.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: fsl-cpm: Verificar la paridad de la longitud antes de cambiar al modo de 16 bits<br /> <br /> El commit fc96ec826bce (&amp;#39;spi: fsl-cpm: Usar el modo de 16 bits para transferencias grandes con tamaño par&amp;#39;) no logró asegurar que el tamaño fuera realmente par antes de cambiar al modo de 16 bits. Hasta hace poco el problema pasó desapercibido porque kernfs utiliza un búfer de rebote preasignado de tamaño PAGE_SIZE para leer la EEPROM.<br /> <br /> Pero el commit 8ad6249c51d0 (&amp;#39;eeprom: at25: convertir a la API spi-mem&amp;#39;) introdujo un búfer de rebote adicional asignado dinámicamente cuyo tamaño es exactamente el tamaño de la transferencia, lo que llevó a un desbordamiento de búfer en el controlador fsl-cpm cuando ese tamaño es impar.<br /> <br /> Añadir la verificación de paridad de longitud faltante y permanecer en el modo de 8 bits cuando la longitud no es par.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> hfsplus: corrige la falta de hfs_bnode_get() en __hfs_bnode_create<br /> <br /> Cuando sync() y link() se llaman concurrentemente, ambos hilos pueden entrar en hfs_bnode_find() sin encontrar el nodo en la tabla hash y proceder a crearlo.<br /> <br /> Hilo A:<br /> hfsplus_write_inode()<br /> -&amp;gt; hfsplus_write_system_inode()<br /> -&amp;gt; hfs_btree_write()<br /> -&amp;gt; hfs_bnode_find(tree, 0)<br /> -&amp;gt; __hfs_bnode_create(tree, 0)<br /> <br /> Hilo B:<br /> hfsplus_create_cat()<br /> -&amp;gt; hfs_brec_insert()<br /> -&amp;gt; hfs_bnode_split()<br /> -&amp;gt; hfs_bmap_alloc()<br /> -&amp;gt; hfs_bnode_find(tree, 0)<br /> -&amp;gt; __hfs_bnode_create(tree, 0)<br /> <br /> En este caso, el hilo A crea el bnode, establece refcnt=1 y lo hashea. El hilo B también intenta crear el mismo bnode, nota que ya ha sido insertado, descarta su propia instancia y usa el hasheado sin obtener el nodo.<br /> <br /> ```<br /> <br /> node2 = hfs_bnode_findhash(tree, cnid);<br /> if (!node2) { &amp;lt;- Hilo A<br /> hash = hfs_bnode_hash(cnid);<br /> node-&amp;gt;next_hash = tree-&amp;gt;node_hash[hash];<br /> tree-&amp;gt;node_hash[hash] = node;<br /> tree-&amp;gt;node_hash_cnt++;<br /> } else { &amp;lt;- Hilo B<br /> spin_unlock(&amp;amp;tree-&amp;gt;hash_lock);<br /> kfree(node);<br /> wait_event(node2-&amp;gt;lock_wq,<br /> !test_bit(HFS_BNODE_NEW, &amp;amp;node2-&amp;gt;flags));<br /> return node2;<br /> }<br /> ```<br /> <br /> Sin embargo, hfs_bnode_find() requiere que cada llamada tome una referencia. Aquí ambos hilos terminan estableciendo refcnt=1. Cuando más tarde liberan el nodo, esto dispara:<br /> <br /> BUG_ON(!atomic_read(&amp;amp;node-&amp;gt;refcnt))<br /> <br /> En este escenario, el Hilo B de hecho encuentra el nodo en la tabla hash en lugar de crear uno nuevo, y por lo tanto debe tomar una referencia.<br /> <br /> Solucione esto llamando a hfs_bnode_get() al reutilizar un bnode recién creado por otro hilo para asegurar que el contador de referencias se actualice correctamente.<br /> <br /> Un error similar fue corregido en HFS hace mucho tiempo en el commit a9dc087fd3c4 (&amp;#39;corrige la falta de hfs_bnode_get() en __hfs_bnode_create&amp;#39;) pero el mismo problema permaneció en HFS+ hasta ahora.

Una vulnerabilidad de carga de archivos arbitraria en el componente /utils/uploadFile de Hubert Imoveis e Administracao Ltda Hub v2.0 1.27.3 permite a los atacantes ejecutar código arbitrario mediante la carga de un archivo PDF manipulado.