Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: phy: intel-xway: solucionar fuga de contador de referencias de nodo OF<br /> <br /> Una revisión automatizada detectó una fuga en el contador de referencias de un nodo OF al verificar si el nodo hijo &amp;#39;leds&amp;#39; existe.<br /> <br /> Llamar a of_put_node() para mantener correctamente el contador de referencias.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: mcba_usb: mcba_usb_read_bulk_callback(): corrige la fuga de memoria de URB<br /> <br /> Corrige una fuga de memoria similar a la del commit 7352e1d5932a (&amp;#39;can: gs_usb: gs_usb_receive_bulk_callback(): corrige la fuga de memoria de URB&amp;#39;).<br /> <br /> En mcba_usb_probe() -&amp;gt; mcba_usb_start(), los URB para transferencias USB de entrada se asignan, se añaden al ancla priv-&amp;gt;rx_submitted y se envían. En la función de callback de completado mcba_usb_read_bulk_callback(), los URB se procesan y se reenvían. En mcba_usb_close() -&amp;gt; mcba_urb_unlink(), los URB se liberan llamando a usb_kill_anchored_urbs(&amp;amp;priv-&amp;gt;rx_submitted).<br /> <br /> Sin embargo, esto no tiene en cuenta que el framework USB desancla el URB antes de que se llame a la función de completado. Esto significa que una vez que un URB de entrada ha sido completado, ya no está anclado y finalmente no se libera en usb_kill_anchored_urbs().<br /> <br /> Corrige la fuga de memoria anclando el URB en mcba_usb_read_bulk_callback() al ancla priv-&amp;gt;rx_submitted.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gpio: cdev: Corregir fugas de recursos ante errores en lineinfo_changed_notify()<br /> <br /> En las rutas de manejo de errores, lineinfo_changed_notify() no libera los recursos asignados, lo que provoca fugas. Corregirlo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: scarlett2: Corrección de desbordamiento de búfer en la recuperación de configuración<br /> <br /> La función scarlett2_usb_get_config() tiene un error lógico en el código de conversión de endianness que puede causar desbordamientos de búfer cuando count &amp;gt; 1.<br /> <br /> El código comprueba &amp;#39;if (size == 2)&amp;#39; donde &amp;#39;size&amp;#39; es el tamaño total del búfer en bytes, luego itera &amp;#39;count&amp;#39; veces tratando cada elemento como u16 (2 bytes). Esto hace que el bucle acceda a &amp;#39;count * 2&amp;#39; bytes cuando el búfer solo tiene &amp;#39;size&amp;#39; bytes asignados.<br /> <br /> Solución comprobando el tamaño del elemento (config_item-&amp;gt;size) en lugar del tamaño total del búfer. Esto asegura que la conversión de endianness coincida con el tipo de elemento real.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: ctxfi: Corrección de posible acceso OOB en el manejo del mezclador de audio<br /> <br /> En el código de manejo del mezclador de audio del controlador ctxfi, el campo &amp;#39;conf&amp;#39; se utiliza como una especie de índice de bucle, y se hace referencia a él en las retrollamadas de índice (amixer_index() y sum_index()).<br /> <br /> Como fue detectado recientemente por fuzzers, el código actual causa acceso OOB en esas funciones.<br /> | UBSAN: índice de array fuera de límites en /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48<br /> | el índice 8 está fuera de rango para el tipo &amp;#39;unsigned char [8]&amp;#39;<br /> <br /> Después del análisis, se encontró que la causa era la falta de la inicialización (o reinicialización) adecuada del campo &amp;#39;conj&amp;#39;.<br /> <br /> Este parche aborda esos accesos OOB añadiendo las inicializaciones adecuadas de los índices de bucle.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rxrpc: Corrección del reenqueque incondicional de recvmsg()<br /> <br /> Si rxrpc_recvmsg() falla porque se especificó MSG_DONTWAIT pero la llamada al frente de la cola de recvmsg ya tiene su mutex bloqueado, reenquequea la llamada, esté o no la llamada ya en la cola. La llamada puede estar en la cola porque también se pasó MSG_PEEK y por lo tanto la llamada no fue desencolada o porque el hilo de E/S la reenquequeó.<br /> <br /> El reenqueque incondicional puede entonces corromper la cola de recvmsg, lo que lleva a cosas como UAFs o subdesbordamientos de refcount.<br /> <br /> Solucione esto reenquequeando la llamada solo si no está ya en la cola, y moviéndola al frente si ya está en la cola. Si no la encolamos, tenemos que liberar la referencia que obtuvimos al desencolarla.<br /> <br /> Además, MSG_PEEK no desencola la llamada, por lo que no debería llamar a rxrpc_notify_socket() para la llamada si no consumimos todos los datos de la cola, así que corrija eso también.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> vsock/virtio: soluciona un posible desbordamiento negativo en virtio_transport_get_credit()<br /> <br /> El cálculo de crédito en virtio_transport_get_credit() utiliza aritmética sin signo:<br /> <br /> ret = vvs-&amp;gt;peer_buf_alloc - (vvs-&amp;gt;tx_cnt - vvs-&amp;gt;peer_fwd_cnt);<br /> <br /> Si el par reduce su búfer anunciado (peer_buf_alloc) mientras hay bytes en tránsito, la resta puede sufrir un desbordamiento negativo y producir un valor positivo grande, lo que podría permitir que se pongan en cola más datos de los que el par puede manejar.<br /> <br /> Reutilizar virtio_transport_has_space() que ya maneja este caso y añadir un comentario para dejar claro por qué lo estamos haciendo.<br /> <br /> [Stefano: usar virtio_transport_has_space() en lugar de duplicar el código]<br /> [Stefano: ajustar el mensaje de commit]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: spi-sprd-adi: Corregir doble liberación en la ruta de error de sondeo<br /> <br /> El controlador actualmente usa spi_alloc_host() para asignar el controlador pero lo registra usando devm_spi_register_controller().<br /> <br /> Si devm_register_restart_handler() falla, el código salta a la etiqueta put_ctlr y llama a spi_controller_put(). Sin embargo, dado que el controlador fue registrado a través de una función devm, el núcleo del dispositivo llamará automáticamente a spi_controller_put() de nuevo cuando el sondeo falle. Esto resulta en una doble liberación de la estructura spi_controller.<br /> <br /> Corregir esto cambiando a devm_spi_alloc_host() y eliminando la llamada manual a spi_controller_put().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iommu/io-pgtable-arm: corrección de error de signo de size_t en la ruta de desmapeo<br /> <br /> __arm_lpae_unmap() devuelve size_t pero estaba devolviendo -ENOENT (código de error negativo) al encontrar una PTE no mapeada. Dado que size_t no tiene signo, -ENOENT (típicamente -2) se convierte en un valor positivo enorme (0xFFFFFFFFFFFFFFFE en sistemas de 64 bits).<br /> <br /> Este valor corrupto se propaga a través de la cadena de llamadas:<br /> __arm_lpae_unmap() devuelve -ENOENT como size_t<br /> -&amp;gt; arm_lpae_unmap_pages() lo devuelve<br /> -&amp;gt; __iommu_unmap() lo añade a la dirección iova<br /> -&amp;gt; iommu_pgsize() activa BUG_ON debido a iova corrupta<br /> <br /> Esto puede causar un desbordamiento de dirección IOVA en el bucle de __iommu_unmap() y activar BUG_ON en iommu_pgsize() por una alineación de dirección inválida.<br /> <br /> Se corrige devolviendo 0 en lugar de -ENOENT. El WARN_ON ya señala la condición de error, y devolver 0 (que significa &amp;#39;nada desmapeado&amp;#39;) es la semántica correcta para el tipo de retorno size_t. Esto coincide con el comportamiento de otras implementaciones de io-pgtable (io-pgtable-arm-v7s, io-pgtable-dart) que devuelven 0 en condiciones de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> platform/x86/amd: Corrección de fuga de memoria en wbrf_record()<br /> <br /> El búfer tmp se asigna usando kcalloc() pero no se libera si acpi_evaluate_dsm() falla. Esto provoca una fuga de memoria en la ruta de error.<br /> <br /> Esto se soluciona liberando explícitamente el búfer tmp en la ruta de manejo de errores de acpi_evaluate_dsm().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: act_ife: evitar posible desreferencia de NULL<br /> <br /> tcf_ife_encode() debe asegurarse de que ife_encode() no devuelva NULL.<br /> <br /> syzbot informó:<br /> <br /> Oops: fallo de protección general, probablemente para dirección no canónica 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: desreferencia de puntero nulo en el rango [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166<br /> CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 No contaminado syzkaller #0 PREEMPT(full)<br /> Traza de Llamada:<br /> <br /> ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101<br /> tcf_ife_encode net/sched/act_ife.c:841 [inline]<br /> tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877<br /> tc_act include/net/tc_wrapper.h:130 [inline]<br /> tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152<br /> tcf_exts_exec include/net/pkt_cls.h:349 [inline]<br /> mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42<br /> tc_classify include/net/tc_wrapper.h:197 [inline]<br /> __tcf_classify net/sched/cls_api.c:1764 [inline]<br /> tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860<br /> multiq_classify net/sched/sch_multiq.c:39 [inline]<br /> multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66<br /> dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147<br /> __dev_xmit_skb net/core/dev.c:4262 [inline]<br /> __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> l2tp: Solucionar fuga de memoria en l2tp_udp_encap_recv().<br /> <br /> syzbot informó una fuga de memoria de struct l2tp_session, l2tp_tunnel, sock, etc. [0]<br /> <br /> El commit citado movió hacia abajo la validación de la versión del protocolo en l2tp_udp_encap_recv().<br /> <br /> El nuevo lugar requiere un manejo de errores adicional para evitar la fuga de memoria.<br /> <br /> Llamemos a l2tp_session_put() allí.<br /> <br /> [0]:<br /> ERROR: fuga de memoria<br /> objeto sin referencia 0xffff88810a290200 (tamaño 512):<br /> comm &amp;#39;syz.0.17&amp;#39;, pid 6086, jiffies 4294944299<br /> volcado hexadecimal (primeros 32 bytes):<br /> 7d eb 04 0c 00 00 00 00 01 00 00 00 00 00 00 00 }...............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> rastreo de pila (crc babb6a4f):<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 /> __do_kmalloc_node mm/slub.c:5656 [inline]<br /> __kmalloc_noprof+0x3e0/0x660 mm/slub.c:5669<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> l2tp_session_create+0x3a/0x3b0 net/l2tp/l2tp_core.c:1778<br /> pppol2tp_connect+0x48b/0x920 net/l2tp/l2tp_ppp.c:755<br /> __sys_connect_file+0x7a/0xb0 net/socket.c:2089<br /> __sys_connect+0xde/0x110 net/socket.c:2108<br /> __do_sys_connect net/socket.c:2114 [inline]<br /> __se_sys_connect net/socket.c:2111 [inline]<br /> __x64_sys_connect+0x1c/0x30 net/socket.c:2111<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