Vulnerabilidades

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

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> i2c: riic: Mover el manejo de suspensión a la fase NOIRQ<br /> <br /> El commit 53326135d0e0 (&amp;#39;i2c: riic: Añadir soporte de suspensión/reanudación&amp;#39;) añadió soporte de suspensión para el controlador I2C de Renesas y, tras este cambio en RZ/G3E, se observa la siguiente ADVERTENCIA al entrar en suspensión...<br /> <br /> [ 134.275704] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)<br /> [ 134.285536] ------------[ cut here ]------------<br /> [ 134.290298] i2c i2c-2: Transfer while suspended<br /> [ 134.295174] WARNING: drivers/i2c/i2c-core.h:56 at __i2c_smbus_xfer+0x1e4/0x214, CPU#0: systemd-sleep/388<br /> [ 134.365507] Tainted: [W]=WARN<br /> [ 134.368485] Hardware name: Renesas SMARC EVK version 2 based on r9a09g047e57 (DT)<br /> [ 134.375961] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 134.382935] pc : __i2c_smbus_xfer+0x1e4/0x214<br /> [ 134.387329] lr : __i2c_smbus_xfer+0x1e4/0x214<br /> [ 134.391717] sp : ffff800083f23860<br /> [ 134.395040] x29: ffff800083f23860 x28: 0000000000000000 x27: ffff800082ed5d60<br /> [ 134.402226] x26: 0000001f4395fd74 x25: 0000000000000007 x24: 0000000000000001<br /> [ 134.409408] x23: 0000000000000000 x22: 000000000000006f x21: ffff800083f23936<br /> [ 134.416589] x20: ffff0000c090e140 x19: ffff0000c090e0d0 x18: 0000000000000006<br /> [ 134.423771] x17: 6f63657320313030 x16: 2e30206465737061 x15: ffff800083f23280<br /> [ 134.430953] x14: 0000000000000000 x13: ffff800082b16ce8 x12: 0000000000000f09<br /> [ 134.438134] x11: 0000000000000503 x10: ffff800082b6ece8 x9 : ffff800082b16ce8<br /> [ 134.445315] x8 : 00000000ffffefff x7 : ffff800082b6ece8 x6 : 80000000fffff000<br /> [ 134.452495] x5 : 0000000000000504 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 134.459672] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c9ee9e80<br /> [ 134.466851] Call trace:<br /> [ 134.469311] __i2c_smbus_xfer+0x1e4/0x214 (P)<br /> [ 134.473715] i2c_smbus_xfer+0xbc/0x120<br /> [ 134.477507] i2c_smbus_read_byte_data+0x4c/0x84<br /> [ 134.482077] isl1208_i2c_read_time+0x44/0x178 [rtc_isl1208]<br /> [ 134.487703] isl1208_rtc_read_time+0x14/0x20 [rtc_isl1208]<br /> [ 134.493226] __rtc_read_time+0x44/0x88<br /> [ 134.497012] rtc_read_time+0x3c/0x68<br /> [ 134.500622] rtc_suspend+0x9c/0x170<br /> <br /> La advertencia se activa porque aún se pueden intentar transferencias I2C mientras el controlador ya está suspendido, debido a un ordenamiento inapropiado de las retrollamadas de suspensión del sistema.<br /> <br /> Si el controlador está autosuspendido, no hay forma de despertarlo una vez que el PM en tiempo de ejecución está deshabilitado (en suspend_late()). Durante la reanudación del sistema, el controlador I2C estará disponible solo después de que el PM en tiempo de ejecución se vuelva a habilitar (en resume_early()). Sin embargo, esto puede ser demasiado tarde para algunos dispositivos.<br /> <br /> Despertar el controlador en la retrollamada suspend() mientras el PM en tiempo de ejecución aún está habilitado. El controlador I2C permanecerá disponible hasta que se llame a la retrollamada suspend_noirq() (pm_runtime_force_suspend()). Durante la reanudación, el controlador I2C puede ser restaurado por la retrollamada resume_noirq() (pm_runtime_force_resume()). Finalmente, la retrollamada resume() vuelve a habilitar la autosuspensión. Como resultado, el controlador I2C puede permanecer disponible hasta que el sistema entre en suspend_noirq() y desde resume_noirq().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> vsock/virtio: Coalescer solo skb lineal<br /> <br /> El común de vsock/virtio intenta coalescer búferes en la cola rx: si un skb lineal (con espacio de cola libre) es seguido por un skb pequeño (longitud limitada por GOOD_COPY_LEN = 128), se intenta unirlos.<br /> <br /> Desde la introducción del soporte MSG_ZEROCOPY, la suposición de que un skb pequeño siempre será lineal es incorrecta. En el caso de zerocopy, se pierden datos y el skb lineal es anexado con memoria del kernel no inicializada.<br /> <br /> De todos los 3 transportes basados en virtio soportados, solo el transporte loopback se ve afectado. La cola rx del transporte virtio G2H opera con skbs explícitamente lineales; ver virtio_vsock_alloc_linear_skb() en virtio_vsock_rx_fill(). El transporte vhost H2G puede asignar skbs no lineales, pero solo para tamaños que no se consideran para la coalescencia; ver PAGE_ALLOC_COSTLY_ORDER en virtio_vsock_alloc_skb().<br /> <br /> Asegurar que solo los skbs lineales sean coalescidos. Tenga en cuenta que skb_tailroom(last_skb) &amp;gt; 0 garantiza que last_skb es lineal.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: kvaser_usb: kvaser_usb_read_bulk_callback(): corregir fuga de memoria de URB<br /> <br /> Corregir fuga de memoria similar a la del commit 7352e1d5932a (&amp;#39;can: gs_usb: gs_usb_receive_bulk_callback(): corregir fuga de memoria de URB&amp;#39;).<br /> <br /> En kvaser_usb_set_{,data_}bittiming() -&amp;gt; kvaser_usb_setup_rx_urbs(), los URB para transferencias USB de entrada se asignan, se añaden al ancla dev-&amp;gt;rx_submitted y se envían. En la función de devolución de llamada completa kvaser_usb_read_bulk_callback(), los URB se procesan y se reenvían. En kvaser_usb_remove_interfaces(), los URB se liberan llamando a usb_kill_anchored_urbs(&amp;amp;dev-&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 completa. 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 /> Corregir la fuga de memoria anclando el URB en kvaser_usb_read_bulk_callback() al ancla dev-&amp;gt;rx_submitted.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: hv_netvsc: rechazar la programación de clave hash RSS sin tabla de indirección RX<br /> <br /> La configuración de RSS requiere una tabla de indirección RX válida. Cuando el dispositivo informa una única cola de recepción, rndis_filter_device_add() no asigna una tabla de indirección; aceptar actualizaciones de clave hash RSS en este estado lleva a un cuelgue.<br /> <br /> Solucionar esto al restringir netvsc_set_rxfh() en ndc-&amp;gt;rx_table_sz y devolver -EOPNOTSUPP cuando la tabla está ausente. Esto alinea set_rxfh con las capacidades del dispositivo y previene un comportamiento incorrecto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> uacce: implementar mremap en uacce_vm_ops para devolver -EPERM<br /> <br /> El uacce_vm_ops actual no soporta la operación mremap de vm_operations_struct. Implementar .mremap para devolver -EPERM para recordar a los usuarios.<br /> <br /> La razón por la que necesitamos deshabilitar explícitamente mremap es que cuando el controlador no implementa .mremap, utiliza el método mremap predeterminado. Esto podría llevar a un escenario de riesgo:<br /> <br /> Una aplicación podría primero mmap la dirección p1, luego mremap a p2, seguido de munmap(p1), y finalmente munmap(p2). Dado que el mremap predeterminado copia el vm_private_data del vma original (es decir, q) al nuevo vma, ambas operaciones munmap activarían vma_close, causando que q-&amp;gt;qfr se libere dos veces (qfr se establecerá en nulo aquí, por lo que la liberación repetida está bien).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: ems_usb: ems_usb_read_bulk_callback(): corregir fuga de memoria de URB<br /> <br /> Corregir fuga de memoria similar a la del commit 7352e1d5932a (&amp;#39;can: gs_usb: gs_usb_receive_bulk_callback(): corregir fuga de memoria de URB&amp;#39;).<br /> <br /> En ems_usb_open(), los URB para transferencias USB de entrada son asignados, añadidos al ancla dev-&amp;gt;rx_submitted y enviados. En la función de devolución de llamada completa ems_usb_read_bulk_callback(), los URB son procesados y reenviados. En ems_usb_close() los URB son liberados llamando a usb_kill_anchored_urbs(&amp;amp;dev-&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 completa. Esto significa que una vez que un URB de entrada ha sido completado, ya no está anclado y finalmente no es liberado en ems_usb_close().<br /> <br /> Corregir la fuga de memoria anclando el URB en la ems_usb_read_bulk_callback() al ancla dev-&amp;gt;rx_submitted.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: qla2xxx: Sanitizar el tamaño de la carga útil para prevenir el desbordamiento de miembro<br /> <br /> En qla27xx_copy_fpin_pkt() y qla27xx_copy_multiple_pkt(), el frame_size reportado por el firmware se utiliza para calcular la longitud de la copia en item-&amp;gt;iocb. Sin embargo, el miembro iocb se define como un array de tamaño fijo de 64 bytes dentro de la estructura purex_item.<br /> <br /> Si el frame_size reportado excede los 64 bytes, las llamadas subsiguientes a memcpy desbordarán el límite del miembro iocb. Aunque se podría asignar memoria adicional, esta escritura entre miembros es insegura y activa advertencias bajo CONFIG_FORTIFY_SOURCE.<br /> <br /> Solucione esto limitando total_bytes al tamaño del miembro iocb (64 bytes) antes de la asignación y la copia. Esto asegura que todas las copias permanezcan dentro de los límites del miembro de la estructura de destino.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> crypto: authencesn - rechazar AAD demasiado corto (assoclen&amp;lt;8) para coincidir con la especificación ESP/ESN<br /> <br /> authencesn asume un AAD con formato ESP/ESN. Cuando assoclen es más corto que la longitud mínima esperada, crypto_authenc_esn_decrypt() puede avanzar más allá del final de la scatterlist de destino y activar una desreferencia de puntero NULL en scatterwalk_map_and_copy(), lo que lleva a un pánico del kernel (DoS).<br /> <br /> Añadir una comprobación de longitud mínima de AAD para fallar rápidamente con entradas no válidas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> platform/x86: hp-bioscfg: Corrección de pánico del kernel en la macro GET_INSTANCE_ID<br /> <br /> La macro GET_INSTANCE_ID que causó un pánico del kernel al acceder a los atributos de sysfs:<br /> <br /> 1. Error de uno: La condición del bucle usaba &amp;#39;&amp;lt;=&amp;#39; en lugar de &amp;#39;&amp;lt;&amp;#39;, causando acceso más allá de los límites del array. Dado que los índices del array están basados en 0 y van de 0 a instances_count-1, el bucle debería usar &amp;#39;&amp;lt;&amp;#39;.<br /> <br /> 2. Falta de comprobación de NULL: El código desreferenció attr_name_kobj-&amp;gt;name sin comprobar si attr_name_kobj era NULL, causando una desreferencia de puntero nulo en min_length_show() y otras funciones de visualización de atributos.<br /> <br /> El pánico ocurrió cuando fwupd intentó leer atributos de configuración del BIOS:<br /> <br /> Oops: general protection fault [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg]<br /> <br /> Añade una comprobación de NULL para attr_name_kobj antes de desreferenciar y corrige el límite del bucle para que coincida con el patrón usado en otras partes del controlador.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> uacce: asegurar la liberación segura de la cola con gestión de estado<br /> <br /> Llamar directamente a &amp;#39;put_queue&amp;#39; conlleva riesgos ya que no puede garantizar que los recursos de &amp;#39;uacce_queue&amp;#39; hayan sido completamente liberados de antemano. Por lo tanto, añadir una operación &amp;#39;stop_queue&amp;#39; para el comando UACCE_CMD_PUT_Q y dejar la operación &amp;#39;put_queue&amp;#39; para la liberación final de recursos garantiza la seguridad.<br /> <br /> Los estados de la cola se definen de la siguiente manera:<br /> - UACCE_Q_ZOMBIE: Estado inicial<br /> - UACCE_Q_INIT: Después de abrir &amp;#39;uacce&amp;#39;<br /> - UACCE_Q_STARTED: Después de que se emite &amp;#39;start&amp;#39; a través de &amp;#39;ioctl&amp;#39;<br /> <br /> Al ejecutar &amp;#39;poweroff -f&amp;#39; en virt mientras el acelerador sigue funcionando, &amp;#39;uacce_fops_release&amp;#39; y &amp;#39;uacce_remove&amp;#39; pueden ejecutarse concurrentemente. Esto puede causar que &amp;#39;uacce_put_queue&amp;#39; dentro de &amp;#39;uacce_fops_release&amp;#39; acceda a un puntero &amp;#39;ops&amp;#39; NULL. Por lo tanto, añadir comprobaciones de estado para evitar acceder a punteros liberados.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amdgpu: corregir pánico de drm por puntero nulo cuando el controlador no soporta atómico<br /> <br /> Cuando el controlador no soporta atómico, fb usa plane-&amp;gt;fb en lugar de plane-&amp;gt;state-&amp;gt;fb.<br /> <br /> (extraído de la confirmación 2f2a72de673513247cd6fae14e53f6c40c5841ef)