Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spufs: corrige una fuga en spufs_create_context() Las correcciones de fugas en 2008 pasaron por alto un caso: si estamos tratando de establecer la afinidad y spufs_mkdir() falla, debemos eliminar la referencia al vecino.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spufs: corrige la duración del directorio de pandillas. Antes de "[POWERPC] spufs: corrige las fugas de destrucción de pandillas", teníamos un problema con la duración de las pandillas: al crear una pandilla, se devolvía el directorio de pandillas abierto, que normalmente se elimina al cerrarse. Sin embargo, si alguien creaba un contexto perteneciente a esa pandilla y lo mantenía activo hasta que se cerraba, la eliminación fallaba y se producía una fuga. Desafortunadamente, se solucionó incorrectamente. La dentry del directorio de pandillas ya no estaba fijada y rmdir al cerrar se había eliminado. Un problema era que, al fallar la apertura, se seguía llamando a simple_rmdir() como limpieza, lo que implicaba un dput() desequilibrado. Otro error, en el caso de éxito, era que la creación de una pandilla incrementaba el número de enlaces en el directorio raíz, pero esto ya no se deshacía al destruirla. La solución consiste en: * revertir el commit en cuestión * añadir un contador a la pandilla, protegido por ->i_rwsem del inodo del directorio de pandillas. * tenerlo establecido en 1 en el momento de la creación, descartado tanto en spufs_dir_close() como en spufs_gang_close() y agregado en spufs_create_context(), siempre que no sea 0. * usar simple_recursive_removal() para sacar el directorio de pandillas cuando el contador llega a cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spufs: se corrige una fuga en caso de fallo de spufs_new_file(). Se llama desde spufs_fill_dir(), y quien lo llama ejecutará spufs_rmdir() en caso de fallo. Esto elimina todo lo que habíamos creado, pero el problema de dentry sigue siendo negativo. Es decir, debe eliminarse explícitamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige la discrepancia entre r_count decrement y decrement. r_count solo aumenta cuando hay una espera de interrupción de oplock, por lo que r_count inc/decrement no se empareja. Esto puede provocar que r_count sea negativo, lo que puede provocar un problema donde el subproceso ksmbd no termina.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtnetlink: Asignar tamaño de vfinfo para GUID de VF cuando sea compatible. el commit 30aad41721e0 ("net/core: Agregar soporte para obtener GUID de VF") agregó soporte para obtener GUID de puerto y nodo de VF en mensajes ifinfo de netlink, pero su tamaño no se tuvo en cuenta en la función que asigna el mensaje de netlink, lo que causa la siguiente advertencia cuando un mensaje de netlink se llena con muchos GUID de puerto y nodo de VF: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK responde: Mensaje demasiado largo. No se puede enviar solicitud de obtención de enlace: Mensaje demasiado largo. Advertencia del kernel: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: se corrige la falta de comprobación de apagado. La prueba genérica/730 de xfstests falló porque, tras eliminar el dispositivo que aún contenía datos corruptos, el archivo aún se podía leer sin devolver un error. El motivo es la falta de comprobación de apagado en ->read_iter. También observé que faltaban comprobaciones de apagado en ->write_iter, ->splice_read y ->mmap. Esta confirmación añade comprobaciones de apagado a todas ellas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Corregir el desequilibrio en el recuento de referencias de netns que causa fugas y use-after-free. el commit ef7134c7fc48 ("smb: cliente: Corregir el use-after-free del espacio de nombres de red") intentó corregir un problema de use-after-free de netns ajustando manualmente los recuentos de referencias mediante sk->sk_net_refcnt y sock_inuse_add(). Sin embargo, una confirmación posterior e9f2517a3e18 ("smb: cliente: Corregir el bloqueo de los temporizadores TCP después de rmmod") indicó que la configuración manual de sk->sk_net_refcnt en la primera confirmación era técnicamente incorrecta, ya que sk->sk_net_refcnt solo debe configurarse para sockets de usuario. Esto provocó problemas como que los temporizadores TCP no se borraran correctamente al cerrar. La segunda confirmación se adaptó a un modelo que simplemente almacena una referencia netns adicional para server->ssocket mediante get_net() y la elimina al desmantelar el servidor. Sin embargo, persisten algunas deficiencias en el equilibrio entre get_net() y put_net(), añadidas por estas confirmaciones. El manejo incompleto de las referencias en estas correcciones genera dos problemas: 1. Fugas de recuento de referencias de netns[1]. El proceso del problema es el siguiente: ``` mount.cifs cifsd cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* Primero, obtener net. */ ip_connect generic_ip_connect /* Intentar el puerto 445 */ get_net() ->connect() /* Error */ put_net() generic_ip_connect /* Intentar el puerto 139 */ get_net() /* Falta put_net() coincidente para este get_net().*/ cifs_get_smb_ses cifs_negotiate_protocol smb2_negotiate SMB2_negotiate cifs_send_recv wait_for_response cifs_demultiplex_thread cifs_read_from_socket cifs_readv_from_socket cifs_reconnect cifs_abort_connection sock_release(); server->ssocket = NULL; /* Falta put_net() aquí. */ generic_ip_connect get_net() ->connect() /* Error */ put_net() sock_release(); server->ssocket = NULL; free_rsp_buf ... clean_demultiplex_info /* Solo se llama una vez aquí. */ put_net() ``` Cuando se activa cifs_reconnect(), el servidor->ssocket se libera sin un put_net() correspondiente para la referencia obtenida previamente en generic_ip_connect(). Termina llamando a generic_ip_connect() de nuevo para reintentar get_net(). Después, el servidor->ssocket se establece en NULL en la ruta de error de generic_ip_connect(), y el recuento neto no se puede liberar en la función clean_demultiplex_info() final. 2. Posible use-after-free. El esquema actual de recuento de referencias puede generar un posible problema de use-after-free en el siguiente escenario: ``` cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net */ ip_connect generic_ip_connect get_net() bind_socket kernel_bind /* failed */ put_net() /* after out_err_crypto_release label */ put_net() /* after out_err label */ put_net() ``` En el proceso de gestión de excepciones donde falla la vinculación del socket, las llamadas get_net() y put_net() están desequilibradas, lo que puede provocar que el recuento de referencias server->net baje a cero y se libere prematuramente. Para solucionar ambos problemas, este parche vincula el recuento de referencias netns ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: no anular el registro del gancho cuando la tabla está inactiva. Cuando nf_tables_updchain detecta un error, es necesario revertir el registro del gancho. Esto solo debe hacerse si el gancho ya está registrado, lo cual no ocurrirá si la tabla está inactiva. Simplemente mueva la asignación al bloque de registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: corrección de la desreferencia de puntero nulo del adaptador al reiniciar. Con SRIOV habilitado, idpf termina llamando a idpf_remove() dos veces. Primero mediante idpf_shutdown() y luego de nuevo cuando idpf_remove() llama a sriov_disable(), porque los dispositivos VF usan el controlador idpf, de ahí la misma rutina de eliminación. Cuando esto sucede, es posible que el adaptador sea nulo desde la primera llamada a idpf_remove(), lo que provoca una desreferencia de puntero nulo. echo 1 > /sys/class/net//device/sriov_numvfs reboot BUG: desreferencia de puntero nulo del kernel, dirección: 000000000000020 ... RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] ... ? idpf_remove+0x22/0x1f0 [idpf] ? idpf_remove+0x1e4/0x1f0 [idpf] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19f/0x200 pci_stop_bus_device+0x6d/0x90 pci_stop_and_remove_bus_device+0x12/0x20 pci_iov_remove_virtfn+0xbe/0x120 sriov_disable+0x34/0xe0 idpf_sriov_configure+0x58/0x140 [idpf] idpf_remove+0x1b9/0x1f0 [idpf] idpf_shutdown+0x12/0x30 [idpf] pci_device_shutdown+0x35/0x60 device_shutdown+0x156/0x200 ... Reemplace la llamada directa a idpf_remove() en idpf_shutdown() con idpf_vc_core_deinit() e idpf_deinit_dflt_mbx(), que realizan la mayor parte de la limpieza, como detener la tarea de inicialización, liberar IRQ, destruir los puertos virtuales y liberar el buzón. Esto evita las llamadas a sriov_disable(), además de una pequeña limpieza de netdev y la destrucción de las colas de trabajo, que no parecen necesarias al apagar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: imx-card: Añadir comprobación de NULL en imx_card_probe(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, imx_card_probe() no comprueba este caso, lo que provoca una desreferencia de puntero NULL. Añadir comprobación de NULL después de devm_kasprintf() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: cadence: Se corrige el acceso fuera de los límites a la matriz en cdns_mrvl_xspi_setup_clock(). Si request_clk > 128, cdns_mrvl_xspi_setup_clock() itera sobre toda la matriz cdns_mrvl_xspi_clk_div_list sin interrumpir la ejecución antes de tiempo, lo que provoca que 'i' sobrepase los límites de la matriz. Para solucionarlo, se detiene el bucle al llegar a la última entrada y se fija el reloj al mínimo de 6,25 MHz. Se corrige la siguiente advertencia con un kernel UBSAN: vmlinux.o: advertencia: objtool: cdns_mrvl_xspi_setup_clock: fin inesperado de la sección .text.cdns_mrvl_xspi_setup_clock

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: disminuir los contadores dst en caché en dst_release La corrección ascendente ac888d58869b ("net: no retrasar dst_entries_add() en dst_release()") se movió y disminuyó el recuento dst de dst_destroy a dst_release para evitar acceder a datos ya liberados en caso de desmantelamiento de netns. Sin embargo, en caso de que CONFIG_DST_CACHE esté habilitado y se usen túneles OvS+, esta corrección está incompleta ya que se verá el mismo problema para los dst en caché: No se puede manejar la solicitud de paginación del núcleo en la dirección virtual ffff5aabf6b5c000 Rastreo de llamadas: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Corrija esto invalidando el caché y, por lo tanto, disminuyendo los contadores dst en caché. dst_release también.