Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> scsi: core: Despertar al manejador de errores cuando las finalizaciones finales compiten entre sí<br /> <br /> El ordenamiento frágil entre marcar comandos como completados o fallidos, de modo que el manejador de errores solo se despierte cuando el último comando en ejecución se complete o agote el tiempo de espera, tiene condiciones de carrera. Estas condiciones de carrera pueden hacer que la capa SCSI no despierte al manejador de errores, dejando la E/S a través del host SCSI atascada ya que el estado de error no puede avanzar.<br /> <br /> Primero, hay un problema de ordenamiento de memoria dentro de scsi_dec_host_busy(). La escritura que borra SCMD_STATE_INFLIGHT puede reordenarse con lecturas que cuentan en scsi_host_busy(). Si bien la CPU local verá su propia escritura, la reordenación puede permitir que otras CPU en scsi_dec_host_busy() o scsi_eh_inc_host_failed() vean un recuento de ocupación elevado, lo que hace que ninguna CPU vea un host ocupado igual al recuento de host_failed.<br /> <br /> Esta condición de carrera puede evitarse con una barrera de memoria en la ruta de error para forzar que la escritura sea visible antes de contar los comandos de host ocupados.<br /> <br /> Segundo, hay un problema de ordenamiento general con scsi_eh_inc_host_failed(). Al contar los comandos ocupados antes de incrementar host_failed, puede competir con un comando final en scsi_dec_host_busy(), de modo que scsi_dec_host_busy() no ve host_failed incrementado, pero scsi_eh_inc_host_failed() cuenta los comandos ocupados antes de que SCMD_STATE_INFLIGHT sea borrado por scsi_dec_host_busy(), lo que resulta en que ninguno despierte la tarea del manejador de errores.<br /> <br /> Esto requiere que la llamada a scsi_host_busy() se mueva después de que host_failed se incremente para cerrar la condición de carrera.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gue: Corrige la fuga de memoria de skb con el protocolo IP interno 0.<br /> <br /> syzbot informó de una fuga de memoria de skb a continuación. [0]<br /> <br /> La reproducción generó un paquete GUE con su protocolo interno 0.<br /> <br /> gue_udp_recv() devuelve -guehdr-&amp;gt;proto_ctype para &amp;#39;resubmit&amp;#39; en ip_protocol_deliver_rcu(), pero esto solo funciona con números de protocolo distintos de cero.<br /> <br /> Descartemos tales paquetes.<br /> <br /> Tenga en cuenta que 0 es un número válido (Opción Salto a Salto de IPv6).<br /> <br /> Creo que no es práctico encapsular HOPOPT en GUE, así que una vez que alguien empiece a quejarse, podríamos pasar un puntero de bandera de reenvío para distinguir dos ceros de la capa superior:<br /> <br /> * sin error<br /> * reenviar HOPOPT<br /> <br /> [0]<br /> BUG: fuga de memoria<br /> objeto sin referencia 0xffff888109695a00 (tamaño 240):<br /> comm &amp;#39;syz.0.17&amp;#39;, pid 6088, jiffies 4294943096<br /> volcado hexadecimal (primeros 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@..............<br /> rastreo (crc a84b336f):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4958 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270<br /> __build_skb+0x23/0x60 net/core/skbuff.c:474<br /> build_skb+0x20/0x190 net/core/skbuff.c:490<br /> __tun_build_skb drivers/net/tun.c:1541 [inline]<br /> tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636<br /> tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770<br /> tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x45d/0x710 fs/read_write.c:686<br /> ksys_write+0xa7/0x170 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netrom: soluciona doble liberación en nr_route_frame()<br /> <br /> En nr_route_frame(), old_skb es liberado inmediatamente sin comprobar si el puntero nr_neigh-&amp;gt;ax25 es NULL. Por lo tanto, si nr_neigh-&amp;gt;ax25 es NULL, la función llamadora liberará old_skb de nuevo, causando un error de doble liberación.<br /> <br /> Por lo tanto, para evitar esto, necesitamos modificarlo para comprobar si nr_neigh-&amp;gt;ax25 es NULL antes de liberar old_skb.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> uacce: corregir la condición de verificación de sysfs de aislamiento<br /> <br /> uacce soporta la característica de aislamiento de dispositivos. Si el controlador implementa las funciones de callback isolate_err_threshold_read e isolate_err_threshold_write, uacce creará archivos sysfs ahora. Los usuarios pueden leer y configurar la política de aislamiento a través de sysfs. Actualmente, los archivos sysfs se crean siempre que estén presentes las funciones de callback isolate_err_threshold_read o isolate_err_threshold_write.<br /> <br /> Sin embargo, acceder a una función de callback inexistente puede causar que el sistema falle. Por lo tanto, interceptar la creación de sysfs si no existe ni lectura ni escritura; crear sysfs si se soporta cualquiera de los dos, pero interceptar las operaciones no soportadas en el sitio de la llamada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: smbd: corrección de dma_unmap_sg() nents<br /> <br /> Las funciones dma_unmap_sg() deben ser llamadas con los mismos nents que la dma_map_sg(), no el valor que la función de mapeo devolvió.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iio: dac: ad3552r-hs: corrección de escritura fuera de límites en ad3552r_hs_write_data_source<br /> <br /> Cuando simple_write_to_buffer() tiene éxito, devuelve el número de bytes realmente copiados al búfer. El código usa incorrectamente &amp;#39;count&amp;#39; como índice para la terminación nula en lugar de los bytes realmente copiados. Si count excede el tamaño del búfer, esto lleva a una escritura fuera de límites. Añadir una comprobación para count y usar el valor de retorno como índice.<br /> <br /> El error fue validado usando un módulo de demostración que refleja el código original y fue probado bajo QEMU.<br /> <br /> Patrón del error:<br /> - Un búfer de pila fijo de 64 bytes se llena usando count.<br /> - Si count &amp;gt; 64, el código aún hace buf[count] = &amp;#39;\0&amp;#39;, causando una<br /> - escritura fuera de límites en la pila.<br /> <br /> Pasos para reproducir:<br /> - Abre el nodo del dispositivo.<br /> - Escribe 128 bytes de A en él.<br /> - Esto desborda el búfer de pila de 64 bytes y KASAN reporta el OOB.<br /> <br /> Encontrado mediante análisis estático. Esto es similar al<br /> commit da9374819eb3 (&amp;#39;iio: backend: corrección de escritura fuera de límites&amp;#39;)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bonding: limitar BOND_MODE_8023AD a dispositivos Ethernet<br /> <br /> BOND_MODE_8023AD solo tiene sentido para ARPHRD_ETHER.<br /> <br /> syzbot informó:<br /> <br /> BUG: KASAN: global-out-of-bounds en __hw_addr_create net/core/dev_addr_lists.c:63 [inline]<br /> BUG: KASAN: global-out-of-bounds en __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118<br /> Lectura de tamaño 16 en la dirección ffffffff8bf94040 por la tarea syz.1.3580/19497<br /> <br /> CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full)<br /> Tainted: [L]=SOFTLOCKUP<br /> Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Traza de Llamadas:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> check_region_inline mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200<br /> __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105<br /> __hw_addr_create net/core/dev_addr_lists.c:63 [inline]<br /> __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118<br /> __dev_mc_add net/core/dev_addr_lists.c:868 [inline]<br /> dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886<br /> bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180<br /> do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963<br /> do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165<br /> rtnl_changelink net/core/rtnetlink.c:3776 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3935 [inline]<br /> rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072<br /> rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958<br /> netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0x21c/0x270 net/socket.c:742<br /> ____sys_sendmsg+0x505/0x820 net/socket.c:2592<br /> ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646<br /> __sys_sendmsg+0x164/0x220 net/socket.c:2678<br /> do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]<br /> __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307<br /> do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332<br /> entry_SYSENTER_compat_after_hwframe+0x84/0x8e<br /> <br /> <br /> La dirección errónea pertenece a la variable:<br /> lacpdu_mcast_addr+0x0/0x40

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> migrate: orden correcto de bloqueo para folios de archivo hugetlb<br /> <br /> Syzbot ha encontrado un interbloqueo (analizado por Lance Yang):<br /> <br /> 1) Tarea (5749): Mantiene folio_lock, luego intenta adquirir i_mmap_rwsem (bloqueo de lectura).<br /> 2) Tarea (5754): Mantiene i_mmap_rwsem (bloqueo de escritura), luego intenta adquirir folio_lock.<br /> <br /> migrate_pages()<br /> -&amp;gt; migrate_hugetlbs()<br /> -&amp;gt; unmap_and_move_huge_page() &amp;lt;- ¡Toma folio_lock!<br /> -&amp;gt; remove_migration_ptes()<br /> -&amp;gt; __rmap_walk_file()<br /> -&amp;gt; i_mmap_lock_read() &amp;lt;- ¡Espera por i_mmap_rwsem (bloqueo de lectura)!<br /> <br /> hugetlbfs_fallocate()<br /> -&amp;gt; hugetlbfs_punch_hole() &amp;lt;- ¡Toma i_mmap_rwsem (bloqueo de escritura)!<br /> -&amp;gt; hugetlbfs_zero_partial_page()<br /> -&amp;gt; filemap_lock_hugetlb_folio()<br /> -&amp;gt; filemap_lock_folio()<br /> -&amp;gt; __filemap_get_folio &amp;lt;- ¡Espera por folio_lock!<br /> <br /> La ruta de migración es la que toma los bloqueos en el orden incorrecto según la documentación en la parte superior de mm/rmap.c. Así que expandir el alcance del i_mmap_lock existente para cubrir también las llamadas a remove_migration_ptes().<br /> <br /> Esto es (en su mayoría) como solía ser después del commit c0d0381ade79. Eso fue eliminado por 336bf30eb765 tanto para páginas hugetlb de archivo como anónimas cuando solo debería haber sido eliminado para páginas hugetlb anónimas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> uacce: corrección del manejo de cdev en la ruta de limpieza<br /> <br /> Cuando cdev_device_add falla, libera internamente la memoria de cdev, y si cdev_device_del se ejecuta entonces, causará un error de bloqueo. Para solucionarlo, verificamos el valor de retorno de cdev_device_add() y borramos uacce-&amp;gt;cdev para evitar llamar a cdev_device_del en uacce_remove.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> leds: led-class: Solo añadir el LED a leds_list cuando esté completamente listo<br /> <br /> Antes de este cambio, el LED se añadía a leds_list antes de que se llamara a led_init_core(), añadiéndolo a la lista antes de que se inicializara led_classdev.set_brightness_work.<br /> <br /> Esto deja una ventana donde led_trigger_register() del disparador predeterminado de un LED llamará a led_trigger_set(), que llama a led_set_brightness(), lo que a su vez terminará encolando el led_classdev.set_brightness_work *no inicializado*.<br /> <br /> Esta condición de carrera es activada por el controlador EC de lenovo-thinkpad-t14s, que registra 2 LEDs con un disparador predeterminado proporcionado por snd_ctl_led.ko en rápida sucesión. La primera llamada a led_classdev_register() provoca la ejecución de un modprobe asíncrono de snd_ctl_led y ese modprobe asíncrono logra alcanzar exactamente la ventana donde el segundo LED está en leds_list sin que se haya llamado a led_init_core() para él, resultando en:<br /> <br /> ------------[ cut here ]------------<br /> ADVERTENCIA: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390<br /> Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025<br /> ...<br /> Rastreo de llamadas:<br /> __flush_work+0x344/0x390 (P)<br /> flush_work+0x2c/0x50<br /> led_trigger_set+0x1c8/0x340<br /> led_trigger_register+0x17c/0x1c0<br /> led_trigger_register_simple+0x84/0xe8<br /> snd_ctl_led_init+0x40/0xf88 [snd_ctl_led]<br /> do_one_initcall+0x5c/0x318<br /> do_init_module+0x9c/0x2b8<br /> load_module+0x7e0/0x998<br /> <br /> Cerrar la ventana de la condición de carrera moviendo la adición del LED a leds_list a después de la llamada a led_init_core().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm/hugetlb: corregir hugetlb_pmd_shared()<br /> <br /> Serie de parches &amp;#39;mm/hugetlb: correcciones para el uso compartido de tablas PMD (incl. el uso de mmu_gather)&amp;#39;, v3.<br /> <br /> Una corrección funcional, una corrección de regresión de rendimiento y dos correcciones de comentarios relacionadas.<br /> <br /> Limpié mi prototipo que compartí recientemente [1] para la corrección de rendimiento, aplazando la mayoría de las limpiezas que tenía en el prototipo para un momento posterior. Mientras hacía eso, identifiqué las otras cosas.<br /> <br /> El objetivo de este conjunto de parches es ser retroportado a árboles estables "bastante" fácilmente. Al menos el parche #1 y #4.<br /> <br /> El parche #1 corrige que hugetlb_pmd_shared() no detecte ningún uso compartido.<br /> El parche #2 + #3 son simples correcciones de comentarios con las que el parche #4 interactúa.<br /> El parche #4 es una corrección para la regresión de rendimiento reportada debido a transmisiones IPI excesivas durante fork()+exit().<br /> <br /> El último parche trata sobre vaciados de TLB, IPIs y mmu_gather.<br /> Léase: complicado<br /> <br /> Hay muchas limpiezas por hacer en el futuro + una optimización razonable en x86. Pero todo eso está fuera del alcance de esta serie.<br /> <br /> Probado en tiempo de ejecución, con un enfoque en corregir la regresión de rendimiento usando el reproductor original [2] en x86.<br /> <br /> Este parche (de 4):<br /> <br /> Cambiamos de usar (erróneamente) el recuento de páginas a un recuento compartido independiente. Ahora, las tablas de páginas compartidas tienen un refcount de 1 (excluyendo referencias especulativas) y en su lugar usan ptdesc-&amp;gt;pt_share_count para identificar el uso compartido.<br /> <br /> No convertimos hugetlb_pmd_shared(), así que ahora mismo, nunca detectaríamos una tabla PMD compartida como tal, porque compartir/dejar de compartir ya no afecta el refcount de una tabla PMD.<br /> <br /> La migración de páginas, como mbind() o migrate_pages(), permitiría migrar folios mapeados en dichas tablas PMD compartidas, aunque los folios no sean exclusivos. En smaps los contabilizaríamos como "privados" aunque sean "compartidos", y estaríamos configurando erróneamente el PM_MMAP_EXCLUSIVE en la interfaz pagemap.<br /> <br /> Corregirlo usando correctamente ptdesc_pmd_is_shared() en hugetlb_pmd_shared().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> intel_th: corrige la fuga de dispositivo al abrir la salida<br /> <br /> Asegúrese de liberar la referencia tomada al buscar el dispositivo th durante la apertura del dispositivo de salida en caso de errores y al cerrar.<br /> <br /> Tenga en cuenta que una confirmación reciente corrigió la fuga en un par de rutas de error de open(), pero no en todas ellas, y la referencia sigue fugándose en una apertura exitosa.