Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: no filtrar almacenamiento propiedad del etiquetador al desvincular el controlador del conmutador. En la confirmación inicial dc452a471dba ("net: dsa: introducir almacenamiento propiedad del etiquetador para datos privados y compartidos"), teníamos una llamada a tag_ops->disconnect(dst) emitida desde dsa_tree_free(), que se llama en el momento del desmontaje del árbol. Había problemas con la conexión a un árbol de conmutadores como un todo, por lo que esto se modificó para conectarse a conmutadores individuales dentro del árbol. En este proceso, tag_ops->disconnect(ds) se hizo para que se llamara solo desde switch.c (notificadores entre chips emitidos como resultado de cambios dinámicos de protocolo de etiqueta), pero la ruta de código normal para el desmontaje del controlador no se reemplazó con nada. Resuelva este problema añadiendo una función que haga lo contrario de dsa_switch_setup_tag_protocol(), que se llama desde el punto equivalente en dsa_switch_teardown(). El posicionamiento aquí también asegura que no tendremos ningún use-after-free en las operaciones del protocolo de etiquetado (*rcv), ya que la secuencia de desmontaje es la siguiente: dsa_tree_teardown -> dsa_tree_teardown_master -> dsa_master_teardown -> anula el ajuste master->dsa_ptr, lo que hace que no haya más paquetes que coincidan con el controlador de tipo de paquete ETH_P_XDSA -> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> anula el registro de los dispositivos de red DSA, incluso hay un synchronize_net() en unregister_netdevice_many() -> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finalmente libera el almacenamiento propiedad del etiquetador

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Se corrigen las llamadas xas_retry() faltantes en la iteración de un xarray. netfslib realiza la iteración de un xarray en varios lugares bajo el bloqueo de lectura de la RCU. *Debería* llamar a xas_retry() como primer paso dentro del bucle y ejecutar "continue" si devuelve verdadero en caso de que el rastreador de xarrays haya pasado un valor especial que indique que el recorrido debe rehacerse desde la raíz. [*] Se puede solucionar añadiendo las comprobaciones de reintento faltantes. [*] Me pregunto si esto debería hacerse dentro de xas_find(), xas_next_node() y similares, pero me han dicho que no es un cambio sencillo de implementar. Esto puede causar un error como el que se muestra a continuación. Observe la dirección del error: se trata de un valor interno (|0x2) devuelto por xarray. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000402 ... RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs] ... Seguimiento de llamadas: netfs_rreq_assess+0xa6/0x240 [netfs] netfs_readpage+0x173/0x3b0 [netfs] ? init_wait_var_entry+0x50/0x50 filemap_read_page+0x33/0xf0 filemap_get_pages+0x2f2/0x3f0 filemap_read+0xaa/0x320 ? do_filp_open+0xb2/0x150 ? rmqueue+0x3be/0xe10 ceph_read_iter+0x1fe/0x680 [ceph] ? new_sync_read+0x115/0x1a0 new_sync_read+0x115/0x1a0 vfs_read+0xf3/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Changes: ======== ver #2) - Se cambió un int sin signo a un size_t para reducir la probabilidad de un desbordamiento según la sugerencia de Willy. - Se agregó un parche adicional para corregir las matemáticas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/x25: Se corrige la fuga de skb en x25_lapb_receive_frame(). x25_lapb_receive_frame() usa skb_copy() para obtener una copia privada de skb. El nuevo skb debe liberarse en la ruta de gestión de errores de skb de tamaño insuficiente/fragmentado. De lo contrario, se produce una fuga de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Corregir la desreferencia de puntero nulo en ftrace_add_mod() @ftrace_mod se asigna mediante kzalloc(), por lo que ambos miembros {prev,next} de @ftrace_mode->list son NULL, no es un estado válido para llamar a list_del(). Si kstrdup() para @ftrace_mod->{func|module} falla, va a la etiqueta @out_free y llama a free_ftrace_mod() para destruir @ftrace_mod, entonces list_del() escribirá prev->next y next->prev, donde ocurre la desreferencia de puntero nulo. ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008 Oops: 0002 [#1] PREEMPT SMP NOPTI Call Trace: ftrace_mod_callback+0x20d/0x220 ? Pánico del kernel: no se sincroniza: Excepción fatal Por lo tanto, llame a INIT_LIST_HEAD() para inicializar el miembro de la lista para corregir este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: Se corrige la pérdida de memoria de nsim_dev->fa_cookie. kmemleak informa de este problema: objeto sin referencia 0xffff8881bac872d0 (tamaño 8): comm "sh", pid 58603, jiffies 4481524462 (edad 68,065 s) volcado hexadecimal (primeros 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] escritura de proxy completo+0xf3/0x180 [<000000005a662c16>] escritura de vfs+0x1c5/0xaf0 [<000000007aabf84a>] escritura de ksys+0xed/0x1c0 [<000000005f1d2e47>] llamada al sistema_64+0x3b/0x90 [<000000006001c6ec>] entrada_SYSCALL_64_after_hwframe+0x63/0xcd El problema ocurre en los siguientes escenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove(): La fa_cookie bloqueada en nsim_dev_trap_fa_cookie_write() no se libera. Para solucionarlo, añada kfree(nsim_dev->fa_cookie) a nsim_drv_remove().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390: evitar el uso de un registro global para current_stack_pointer. El commit 30de14b1884b ("s390: current_stack_pointer no debería ser una función") convirtió current_stack_pointer en una variable de registro global, como en muchas otras arquitecturas. Desafortunadamente, en s390, se descubre un antiguo error de gcc corregido solo desde gcc-9.1 [commit 3ad7fed1cc87 de gcc ("S/390: Corrección de PR89775. Se eliminaron las instrucciones de guardado/restauración de Stackpointer")] y se ha retroportado a gcc-8.4 y posteriores. Debido a este error, las versiones de gcc anteriores a la 8.4 generan código defectuoso que provoca corrupciones en la pila. La versión mínima actual de gcc requerida para compilar el kernel es la 5.1. No es posible corregir todas las versiones antiguas de gcc, por lo que se puede solucionar este problema evitando el uso de la variable de registro global para current_stack_pointer.