Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipv6: Solucionar desajuste en el recuento de hermanos ECMP al borrar RTF_ADDRCONF<br /> <br /> syzbot informó un BUG del kernel en fib6_add_rt2node() al añadir una ruta IPv6. [0]<br /> <br /> El commit f72514b3c569 (&amp;#39;ipv6: borrar flags RA al añadir una ruta estática&amp;#39;) introdujo lógica para borrar RTF_ADDRCONF de rutas existentes cuando se añade una ruta estática con el mismo nexthop. Sin embargo, esto causa un problema cuando la ruta existente tiene una puerta de enlace.<br /> <br /> Cuando se borra RTF_ADDRCONF de una ruta que tiene una puerta de enlace, esa ruta se vuelve elegible para ECMP, es decir, rt6_qualify_for_ecmp() devuelve verdadero. El problema es que esta ruta nunca fue añadida a la lista fib6_siblings.<br /> <br /> Esto lleva a un desajuste entre los siguientes recuentos:<br /> <br /> - El recuento de hermanos calculado al iterar la cadena fib6_next, que incluye la ruta recién elegible para ECMP<br /> <br /> - Los hermanos reales en la lista fib6_siblings, que no incluye esa ruta<br /> <br /> Cuando se añade una ruta ECMP subsiguiente, fib6_add_rt2node() encuentra BUG_ON(sibling-&amp;gt;fib6_nsiblings != rt-&amp;gt;fib6_nsiblings) porque los recuentos no coinciden.<br /> <br /> Solucione esto borrando RTF_ADDRCONF solo cuando la ruta existente no tiene una puerta de enlace. Las rutas sin una puerta de enlace no pueden calificar para ECMP de todos modos (rt6_qualify_for_ecmp() requiere fib_nh_gw_family), por lo tanto, borrar RTF_ADDRCONF en ellas es seguro y coincide con la intención original del commit.<br /> <br /> [0]:<br /> BUG del kernel en net/ipv6/ip6_fib.c:1217!<br /> Oops: código de operación inválido: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 No contaminado syzkaller #0 PREEMPT(full)<br /> Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> RIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217<br /> [...]<br /> Traza de llamada:<br /> <br /> fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532<br /> __ip6_ins_rt net/ipv6/route.c:1351 [en línea]<br /> ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946<br /> ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571<br /> inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577<br /> sock_do_ioctl+0xdc/0x300 net/socket.c:1245<br /> sock_ioctl+0x576/0x790 net/socket.c:1366<br /> vfs_ioctl fs/ioctl.c:51 [en línea]<br /> __do_sys_ioctl fs/ioctl.c:597 [en línea]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [en línea]<br /> do_syscall_64+0xfa/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 /> ceph: corrige un oops debido a un puntero inválido para kfree() en parse_longname()<br /> <br /> Esto corrige un oops del kernel al leer directorios de instantáneas de ceph (.snap), por ejemplo, simplemente ejecutando &amp;#39;ls /mnt/my_ceph/.snap&amp;#39;.<br /> <br /> La variable str está protegida por __free(kfree), pero se avanza en uno para saltar el &amp;#39;_&amp;#39; inicial en los nombres de las instantáneas. Por lo tanto, se llama a kfree() con un puntero inválido. Este parche elimina la necesidad de avanzar el puntero para que se llame a kfree() con el puntero de memoria correcto.<br /> <br /> Pasos para reproducir:<br /> <br /> 1. Crea instantáneas en un volumen cephfs (tengo 63 instantáneas en mi caso de prueba)<br /> <br /> 2. Añade el montaje cephfs a fstab<br /> $ echo &amp;#39;samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0&amp;#39; &amp;gt;&amp;gt; /etc/fstab<br /> <br /> 3. Reinicia el sistema<br /> $ systemctl reboot<br /> <br /> 4. Comprueba si está realmente montado<br /> $ mount | grep stuff<br /> <br /> 5. Lista las instantáneas (se esperan 63 instantáneas en mi sistema)<br /> $ ls /mnt/test/stuff/.snap<br /> <br /> Ahora ls se cuelga indefinidamente y el registro del kernel muestra el oops.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cgroup/dmem: corrección de desreferencia de puntero NULL al establecer el máximo<br /> <br /> Un problema se desencadenó:<br /> <br /> BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000000<br /> #PF: acceso de lectura de supervisor en modo kernel<br /> #PF: código_de_error(0x0000) - página no presente<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 15 UID: 0 PID: 658 Comm: bash Tainted: 6.19.0-rc6-next-2026012<br /> Tainted: [O]=OOT_MODULE<br /> Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996),<br /> RIP: 0010:strcmp+0x10/0x30<br /> RSP: 0018:ffffc900017f7dc0 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888107cd4358<br /> RDX: 0000000019f73907 RSI: ffffffff82cc381a RDI: 0000000000000000<br /> RBP: ffff8881016bef0d R08: 000000006c0e7145 R09: 0000000056c0e714<br /> R10: 0000000000000001 R11: ffff888107cd4358 R12: 0007ffffffffffff<br /> R13: ffff888101399200 R14: ffff888100fcb360 R15: 0007ffffffffffff<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000105c79000 CR4: 00000000000006f0<br /> Rastro de Llamada:<br /> <br /> dmemcg_limit_write.constprop.0+0x16d/0x390<br /> ? __pfx_set_resource_max+0x10/0x10<br /> kernfs_fop_write_iter+0x14e/0x200<br /> vfs_write+0x367/0x510<br /> ksys_write+0x66/0xe0<br /> do_syscall_64+0x6b/0x390<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f42697e1887<br /> <br /> Se desencadenó al establecer el máximo sin limitación, el comando es como:<br /> "echo test/region0 &amp;gt; dmem.max". Para solucionar este problema, añadir una comprobación de si las opciones son válidas después de analizar el region_name.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> binder: corregir UAF en binder_netlink_report()<br /> <br /> Las transacciones unidireccionales enviadas a objetivos congelados a través de binder_proc_transaction() devuelven un error BR_TRANSACTION_PENDING_FROZEN pero aún se tratan como exitosas ya que se espera que el objetivo se descongele en algún momento. Por lo tanto, no es seguro acceder a &amp;#39;t&amp;#39; después de errores BR_TRANSACTION_PENDING_FROZEN, ya que la transacción podría haber sido consumida por el objetivo ahora descongelado.<br /> <br /> Este es el caso de binder_netlink_report() que desreferencia &amp;#39;t&amp;#39; después de un error de congelación pendiente, como lo señala el siguiente informe KASAN:<br /> <br /> ==================================================================<br /> ERROR: KASAN: uso después de liberación de slab en binder_netlink_report.isra.0+0x694/0x6c8<br /> Lectura de tamaño 8 en la dirección ffff00000f98ba38 por la tarea binder-util/522<br /> <br /> CPU: 4 UID: 0 PID: 522 Comm: binder-util No contaminado 6.19.0-rc6-00015-gc03e9c42ae8f #1 PREEMPT<br /> Nombre del hardware: linux,dummy-virt (DT)<br /> Rastro de llamada:<br /> binder_netlink_report.isra.0+0x694/0x6c8<br /> binder_transaction+0x66e4/0x79b8<br /> binder_thread_write+0xab4/0x4440<br /> binder_ioctl+0x1fd4/0x2940<br /> [...]<br /> <br /> Asignado por la tarea 522:<br /> __kmalloc_cache_noprof+0x17c/0x50c<br /> binder_transaction+0x584/0x79b8<br /> binder_thread_write+0xab4/0x4440<br /> binder_ioctl+0x1fd4/0x2940<br /> [...]<br /> <br /> Liberado por la tarea 488:<br /> kfree+0x1d0/0x420<br /> binder_free_transaction+0x150/0x234<br /> binder_thread_read+0x2d08/0x3ce4<br /> binder_ioctl+0x488/0x2940<br /> [...]<br /> ==================================================================<br /> <br /> En su lugar, haga una copia de la transacción para que los datos puedan ser accedidos de forma segura por binder_netlink_report() después de un error de congelación pendiente. Ya que estamos, añada un comentario sobre no usar t-&amp;gt;buffer en binder_netlink_report().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: iwlwifi: mld: cancelar mlo_scan_start_wk<br /> <br /> mlo_scan_start_wk no se cancela en la desconexión. De hecho, no se<br /> cancela en ningún otro lugar excepto en la limpieza de reinicio, donde<br /> realmente no es necesario.<br /> <br /> Esto puede causar un problema de inicialización después de la cola: si,<br /> por ejemplo, el trabajo fue puesto en cola y luego se ejecutó<br /> drv_change_interface.<br /> <br /> Esto también puede causar uso después de liberación: si el trabajo se<br /> ejecuta después de que se libera el vif.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> hwmon: (acpi_power_meter) Soluciona interbloqueos relacionados con acpi_power_meter_notify()<br /> <br /> La función de callback .notify() del controlador acpi_power_meter, acpi_power_meter_notify(), llama a hwmon_device_unregister() bajo un bloqueo que también es adquirido por callbacks en atributos sysfs del dispositivo que se está desregistrando, lo cual es propenso a interbloqueos entre el acceso a sysfs y la eliminación del dispositivo.<br /> <br /> Aborda esto moviendo la eliminación del dispositivo hwmon en acpi_power_meter_notify() fuera del bloqueo en cuestión, pero ten en cuenta que hacerlo solo no es suficiente porque dos notificaciones METER_NOTIFY_CONFIG concurrentes pueden estar intentando eliminar el mismo dispositivo al mismo tiempo. Para evitar que eso suceda, añade un nuevo bloqueo serializando la ejecución de la sentencia switch () en acpi_power_meter_notify(). Para simplificar, es un mutex estático lo cual no debería ser un problema desde la perspectiva del rendimiento.<br /> <br /> El nuevo bloqueo también permite que hwmon_device_register_with_info() en acpi_power_meter_notify() sea llamado fuera del bloqueo interno porque evita que las otras notificaciones manejadas por esa función manipulen el objeto &amp;#39;resource&amp;#39; mientras el dispositivo hwmon basado en él está siendo registrado. El envío de mensajes netlink ACPI desde acpi_power_meter_notify() también es serializado por el nuevo bloqueo, lo cual generalmente ayuda a asegurar que el orden de manejo de las notificaciones de firmware es el mismo que el orden de envío de los mensajes netlink relacionados con ellas.<br /> <br /> Además, ten en cuenta que hwmon_device_register_with_info() puede fallar, en cuyo caso resource-&amp;gt;hwmon_dev se convertirá en un puntero de error, así que añade comprobaciones para evitar intentar desregistrar el dispositivo hwmon al que apunta en ese caso a acpi_power_meter_notify() y acpi_power_meter_remove().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> pmdomain: imx8m-blk-ctrl: corrige el acceso fuera de rango de bc-&amp;gt;domains<br /> <br /> Corrige el acceso fuera de rango de bc-&amp;gt;domains en imx8m_blk_ctrl_remove().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: usb: r8152: corregir interbloqueo de reinicio de reanudación<br /> <br /> rtl8152 puede desencadenar un reinicio del dispositivo durante el reinicio, lo que potencialmente puede resultar en un interbloqueo:<br /> <br /> ** Tiempo de espera agotado del dispositivo DPM después de 10 segundos; 15 segundos hasta el pánico **<br /> Rastreo de llamadas:<br /> <br /> schedule+0x483/0x1370<br /> schedule_preempt_disabled+0x15/0x30<br /> __mutex_lock_common+0x1fd/0x470<br /> __rtl8152_set_mac_address+0x80/0x1f0<br /> dev_set_mac_address+0x7f/0x150<br /> rtl8152_post_reset+0x72/0x150<br /> usb_reset_device+0x1d0/0x220<br /> rtl8152_resume+0x99/0xc0<br /> usb_resume_interface+0x3e/0xc0<br /> usb_resume_both+0x104/0x150<br /> usb_resume+0x22/0x110<br /> <br /> El problema es que la reanudación de rtl8152 llama a reset bajo el mutex tp-&amp;gt;control mientras que reset básicamente reingresa a rtl8152 e intenta adquirir el mismo bloqueo tp-&amp;gt;control una vez más.<br /> <br /> Reiniciar el dispositivo INACCESIBLE fuera del ámbito del mutex tp-&amp;gt;control para evitar el interbloqueo recursivo de mutex_lock().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ceph: soluciona la desreferencia de puntero NULL en ceph_mds_auth_match()<br /> <br /> El cliente del kernel de CephFS tiene una regresión a partir de 6.18-rc1.<br /> Tenemos un problema en ceph_mds_auth_match() si fs_name == NULL:<br /> <br /> const char fs_name = mdsc-&amp;gt;fsc-&amp;gt;mount_options-&amp;gt;mds_namespace;<br /> ...<br /> if (auth-&amp;gt;match.fs_name &amp;amp;&amp;amp; strcmp(auth-&amp;gt;match.fs_name, fs_name)) {<br /> / el nombre de sistema de archivos no coincide, intentar el siguiente */<br /> return 0;<br /> }<br /> <br /> Patrick Donnelly sugirió que: En resumen, definitivamente deberíamos empezar a decodificar &amp;#39;fs_name&amp;#39; del MDSMap y realizar controles de autorización estrictos contra él. Tenga en cuenta que &amp;#39;-o mds_namespace=foo&amp;#39; solo debe usarse para seleccionar el sistema de archivos a montar y nada más. Es posible que no se especifique ningún mds_namespace, pero el kernel montará el único sistema de archivos que existe, el cual puede tener el nombre &amp;#39;foo&amp;#39;.<br /> <br /> Este parche reelabora ceph_mdsmap_decode() y namespace_equals() con el objetivo de apoyar el concepto sugerido. Ahora la estructura ceph_mdsmap contiene el campo m_fs_name que recibe una copia del nombre de FS extraído por ceph_extract_encoded_string(). Para el caso de sistemas de archivos CephFS &amp;#39;antiguos&amp;#39;, se utiliza el nombre &amp;#39;cephfs&amp;#39;.<br /> <br /> [ idryomov: reemplazar el redundante %*pE con %s en ceph_mdsmap_decode(), eliminar una serie de llamadas a strlen() en ceph_namespace_match(), descartar cambios en el cuerpo de namespace_equals() para evitar tratar un mds_namespace vacío como igual, descartar cambios en ceph_mdsc_handle_fsmap() ya que namespace_equals() no es una sustitución equivalente allí ]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ASoC: amd: corrección de fuga de memoria en las operaciones DMA de pdm acp3x

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: aloop: Corrige el acceso con condiciones de carrera en el disparador PCM<br /> <br /> La función de devolución de llamada del disparador PCM del controlador aloop intenta verificar el estado de PCM y detener el flujo del subflujo vinculado en el cable correspondiente. Dado que tanto las operaciones de verificación como las de detención se realizan fuera del bloqueo del cable, esto puede resultar en UAF cuando un programa intenta disparar frecuentemente mientras abre/cierra el flujo vinculado, como detectaron los fuzzers.<br /> <br /> Para abordar el UAF, este parche cambia dos cosas:<br /> - Cubre la mayor parte del código en loopback_check_format() con el spinlock cable-&amp;gt;lock, y añade las comprobaciones de NULL adecuadas. Esto ya evita algunos accesos con condiciones de carrera.<br /> - Además, ahora intentamos verificar el estado del flujo PCM de captura que puede ser detenido en esta función, lo cual era el principal punto problemático que conducía al UAF.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvme-pci: manejar los requisitos cambiantes del mapa dma del dispositivo<br /> <br /> El estado inicial de dma_needs_unmap puede ser falso, pero cambiar a verdadero mientras se mapea el iterador de datos. Habilitar swiotlb es uno de esos casos que puede cambiar el resultado. El controlador nvme necesita guardar los vectores dma mapeados para ser desmapeados más tarde, así que asignar según sea necesario durante la iteración en lugar de asumir que siempre fue asignado al principio. Esto corrige una desreferencia NULL al acceder a un dma_vecs no inicializado cuando los requisitos de desmapeo dma del dispositivo cambian a mitad de la iteración.