Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: target: iscsi: Corrección de uso después de liberación en iscsit_dec_session_usage_count()<br /> <br /> En iscsit_dec_session_usage_count(), la función llama a complete() mientras mantiene el sess-&amp;gt;session_usage_lock. Similar a la lógica de conteo de uso de la conexión, el hilo en espera señalado por complete() (por ejemplo, en la ruta de liberación de la sesión) puede despertar y liberar la estructura iscsit_session inmediatamente.<br /> <br /> Esto crea una condición de carrera donde el hilo actual puede intentar ejecutar spin_unlock_bh() en una estructura de sesión que ya ha sido desasignada, lo que resulta en un KASAN slab-uso después de liberación.<br /> <br /> Para resolver esto, liberar el session_usage_lock antes de llamar a complete() para asegurar que todas las desreferencias del puntero sess hayan terminado antes de que se permita al hilo en espera proceder con la desasignación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> linkwatch: usar __dev_put() en las funciones que llaman para prevenir UAF<br /> <br /> Después de que linkwatch_do_dev() llama a __dev_put() para liberar la referencia de linkwatch, el contador de referencias del dispositivo puede bajar a 1. En este punto, netdev_run_todo() puede continuar (ya que linkwatch_sync_dev() ve una lista vacía y regresa sin bloquear), esperar a que el contador de referencias llegue a 1 a través de netdev_wait_allrefs_any(), y luego liberar el dispositivo a través de kobject_put().<br /> <br /> Esto crea un uso después de liberación cuando __linkwatch_run_queue() intenta llamar a netdev_unlock_ops() en el dispositivo ya liberado.<br /> <br /> Tenga en cuenta que añadir el par netdev_lock_ops()/netdev_unlock_ops() en netdev_run_todo() antes de kobject_put() no funcionaría, porque netdev_lock_ops() es condicional - solo bloquea cuando netdev_need_ops_lock() devuelve verdadero. Si el dispositivo no requiere ops_lock, linkwatch no mantendrá ningún bloqueo, y netdev_run_todo() al adquirir el bloqueo no proporcionará sincronización.<br /> <br /> Solucione esto moviendo __dev_put() de linkwatch_do_dev() a sus funciones que llaman. La referencia del dispositivo se empareja lógicamente con la eliminación del dispositivo de la lista, por lo que es razonable que la función que realizó la eliminación de la lista lo libere. Esto permite colocar __dev_put() después de que todos los accesos al dispositivo estén completos, previniendo UAF.<br /> <br /> El error puede reproducirse añadiendo mdelay(2000) después de linkwatch_do_dev() en __linkwatch_run_queue(), luego ejecutando:<br /> <br /> ip tuntap add mode tun name tun_test<br /> ip link set tun_test up<br /> ip link set tun_test carrier off<br /> ip link set tun_test carrier on<br /> sleep 0.5<br /> ip tuntap del mode tun name tun_test<br /> <br /> Informe KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: uso después de liberación in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> BUG: KASAN: uso después de liberación in netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> BUG: KASAN: uso después de liberación in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123<br /> <br /> CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Workqueue: events_unbound linkwatch_event<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x156/0x4c9 mm/kasan/report.c:482<br /> kasan_report+0xdf/0x1a0 mm/kasan/report.c:595<br /> netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304<br /> process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x5da/0xe40 kernel/workqueue.c:3421<br /> kthread+0x3b3/0x730 kernel/kthread.c:463<br /> ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> ==================================================================

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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.