Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige la fuga de conexiones al fallar la configuración de Tlink. Si la configuración de Tlink falla, se pierden las conexiones y se produce una fuga de referencia del módulo, ya que el kthread de cifsd no finaliza. También se filtra la información de fscache, y en el siguiente montaje con fsc, se mostrarán los siguientes errores: CIFS: La clave del volumen de caché ya está en uso (cifs,127.0.0.1:445,TEST). Revisemos el resultado de la configuración de Tlink y realicemos una limpieza.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mISDN: corrige posible pérdida de memoria en mISDN_dsp_element_register() Después de la confirmación 1fa5ae857bb1 ("núcleo del controlador: deshacerse de la matriz de cadenas bus_id del dispositivo struct"), el nombre del dispositivo se asigna dinámicamente, use put_device() para renunciar a la referencia, de modo que el nombre se pueda liberar en kobject_cleanup() cuando refcount sea 0. La 'entrada' se liberará en mISDN_dsp_dev_release(), por lo que se elimina kfree(). list_del() se llama en mISDN_dsp_dev_release(), por lo que necesita inicializarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mctp i2c: no cuente las claves no utilizadas o no válidas para la liberación del flujo Actualmente estamos alcanzando el WARN_ON en mctp_i2c_flow_release: if (midev->release_count > midev->i2c_lock_count) { WARN_ONCE(1, "release count overflow"); Esto puede ser alcanzado si expiramos un flujo antes de enviar el primer paquete que contiene, ya que no estaremos emparejando el incremento de release_count (realizado en la liberación del flujo) con la operación de bloqueo i2c (solo se realiza en TX real). Para corregir esto, solo libere un flujo si lo hemos encontrado previamente (es decir, dev_flow_state no indica NUEVO), ya que marcaremos el flujo como ACTIVO al mismo tiempo que contabilizamos la operación de bloqueo i2c. También necesitamos agregar un estado de flujo INVÁLIDO, para indicar cuándo hemos realizado la liberación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeon_ep: se corrige una posible fuga de memoria en octep_device_setup(). Cuando se producen errores unsupported_dev e init de mbox, no se liberan oct->conf ni iounmap() de oct->mmio[i].hw_addr. Esto causaría un problema de fuga de memoria. Se añaden kfree() para oct->conf e iounmap() para oct->mmio[i].hw_addr en los errores unsupported_dev e init de mbox para solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mISDN: corregir el uso incorrecto de put_device() en mISDN_register_device() No debemos liberar la referencia de put_device() antes de llamar a device_initialize().

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: se corrige la falta de xas_retry() en el modo fscache. La iteración del array x solo mantiene el bloqueo de lectura de la RCU y, por lo tanto, puede encontrar XA_RETRY_ENTRY si hay un proceso que modifica el array x simultáneamente. Esto causará errores al hacer referencia a la entrada no válida. Se soluciona añadiendo la falta de xas_retry(), lo que hará que la iteración regrese al nodo raíz si se encuentra XA_RETRY_ENTRY.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kcm: condiciones de ejecución cerradas en sk_receive_queue. sk->sk_receive_queue está protegido por el bloqueo de cola skb, pero para los sockets KCM su ruta RX toma mux->rx_lock para proteger más que solo la cola skb. Sin embargo, kcm_recvmsg() todavía solo captura el bloqueo de cola skb, por lo que las condiciones de ejecución aún existen. Podemos enseñar a kcm_recvmsg() a capturar también mux->rx_lock, pero esto introduciría una posible regresión del rendimiento, ya que la estructura kcm_mux puede ser compartida por varios sockets KCM. Por lo tanto, debemos aplicar el bloqueo de cola skb en requeue_rx_msgs() y manejar el caso de skb peek con cuidado en kcm_wait_data(). Afortunadamente, skb_recv_datagram() ya lo gestiona correctamente y es ampliamente utilizado por otros sockets. Podemos cambiar a skb_recv_datagram() tras eliminar el bloqueo de sock innecesario en kcm_recvmsg() y kcm_splice_read(). Nota: Los sockets KCM no utilizan SOCK_DONE, por lo que también es seguro omitir esta comprobación. Ejecuté el reproductor syzbot original durante 30 minutos sin observar ningún problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ena: Se corrige el manejo de errores en ena_init(). Ena_init() no destruye la cola de trabajo creada por create_singlethread_workqueue() cuando pci_register_driver() falla. Se llama a destroy_workqueue() cuando pci_register_driver() falla para evitar la fuga de recursos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bridge: switchdev: Fix memory leakage when Changing VLAN protocol El controlador del puente puede descargar VLAN al hardware subyacente mediante switchdev o el controlador 8021q. Cuando se utiliza el primero, la VLAN se marca en el controlador del puente con el indicador privado 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. Para evitar las fugas de memoria mencionadas en la confirmación citada, el controlador del puente intentará eliminar una VLAN mediante el controlador 8021q si la VLAN no está marcada con el indicador mencionado anteriormente. Cuando cambia el protocolo VLAN del puente, se notifica a los controladores switchdev mediante el atributo 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL', pero también se llama al controlador 8021q para agregar las VLAN existentes con el nuevo protocolo y eliminarlas con el protocolo anterior. En caso de que las VLAN se descargaran mediante switchdev, el comportamiento anterior es redundante y presenta errores. Redundante porque las VLAN ya están programadas en el hardware y los controladores compatibles con el cambio de protocolo de VLAN (actualmente solo mlx5) cambian el protocolo al recibir la notificación del atributo switchdev. Presenta errores porque se llama al controlador 8021q a pesar de que estas VLAN están marcadas con 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. Esto provoca fugas de memoria [1] al eliminar las VLAN. Se soluciona no llamando al controlador 8021q para las VLAN ya programadas mediante switchdev. [1] objeto sin referencia 0xffff8881f6771200 (tamaño 256): comm "ip", pid 446855, jiffies 4298238841 (edad 55.240s) volcado hexadecimal (primeros 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drbd: use-after-free en drbd_create_device(). drbd_destroy_connection() libera la "conexión", así que use el iterador _safe() para evitar un use-after-free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: corrige una pérdida de memoria en nvmet_auth_set_key Al cambiar los secretos de dhchap, también debemos liberar los secretos antiguos. Queja de kmemleak: -- objeto sin referencia 0xffff8c7f44ed8180 (tamaño 64): comm "check", pid 7304, jiffies 4295686133 (edad 72034.246s) volcado hexadecimal (primeros 32 bytes): 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8 backtrace: [<00000000b6fc5071>] kstrdup+0x2e/0x60 [<00000000f0f4633f>] 0xffffffffc0e07ee6 [<0000000053006c05>] 0xffffffffc0dff783 [<00000000419ae922>] configfs_write_iter+0xb1/0x120 [<000000008183c424>] vfs_write+0x2be/0x3c0 [<000000009005a2a5>] ksys_write+0x5f/0xe0 [<00000000cd495c89>] do_syscall_64+0x38/0x90 [<00000000f2a84ac5>] entry_SYSCALL_64_after_hwframe+0x63/0xcd