Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ublk: asegurar que `ubq->canceling` esté configurado cuando la cola esté congelada. Ahora, el controlador ublk depende de `ubq->canceling` para decidir si la solicitud puede enviarse mediante `uring_cmd` e `io_uring_cmd_complete_in_task()`. Una vez configurado `ubq->canceling`, el `uring_cmd` puede enviarse mediante `ublk_cancel_cmd()` e `io_uring_cmd_done()`. Por lo tanto, al configurar `ubq->canceling` cuando la cola esté congelada, se garantiza que el indicador se pueda observar desde `ublk_queue_rq()` de forma fiable y se evita el `use-after-free` en `uring_cmd`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: fgraph: Se corrige el diseño de la pila para que coincida con el argumento __arch_ftrace_regs de ftrace_return_to_handler Naresh Kamboju informó una advertencia del kernel "Puntero de marco incorrecto" mientras ejecutaba el seguimiento LTP ftrace_stress_test.sh en riscv. Podemos reproducir el mismo problema con el siguiente comando: ``` $ cd /sys/kernel/debug/tracing $ echo 'f:myprobe do_nanosleep%return args1=$retval' > dynamic_events $ echo 1 > events/fprobes/enable $ echo 1 > tracing_on $ sleep 1 ``` Y podemos obtener la siguiente advertencia del kernel: [ 127.692888] ------------[ cortar aquí ]------------ [ 127.693755] Puntero de marco incorrecto: se esperaba ff2000000065be50, se recibió ba34c141e9594000 [ 127.693755] de func do_nanosleep return a ffffffff800ccb16 [ 127.698699] ADVERTENCIA: CPU: 1 PID: 129 en kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be [ 127.699894] Módulos vinculados en: [ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep No contaminado 6.14.0-rc3-g0ab191c74642 #32 [ 127.701453] Nombre del hardware: riscv-virtio,qemu (DT) [ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be [ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be [ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10 [ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000 [ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80 [ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1: ffffffff81894f20 [127.702408] a2: 0000000000000010 a3: fffffffffffffffffe a4: 00000000000000000 [127.702470] a5: 0000000000000000 a6: 0000000000000008 a7: 0000000000000038 [127.702530] s2: ba34c141e9594000 s3: 0000000000000000 s4: ff2000000065bdd0 [127.702591] s5: 00007fff8adcf400 s6: 000055556dc1d8c0 s7: 00000000000000068 [127.702651] s8: 00007fff8adf5d10 s9: 000000000000006d s10: 0000000000000001 [127.702710] s11: 00005555737377c8 t3: ffffffff819d899e t4: ffffffff819d899e [ 127.702769] t5: ffffffff819d89a0 t6: ff2000000065bb18 [127.702826] estado: 0000000200000120 dirección incorrecta: 0000000000000000 causa: 0000000000000003 [127.703292] [] ftrace_return_to_handler+0x1b2/0x1be [127.703760] [] return_to_handler+0x16/0x26 [127.704009] [] retorno_al_controlador+0x0/0x26 [ 127.704057] [] suspensión_común+0x42/0x54 [ 127.704117] [] __riscv_sys_clock_nanosleep+0xba/0x10a [ 127.704176] [] hacer_trampa_ecall_u+0x188/0x218 [ 127.704295] [] controlar_excepción+0x14a/0x156 [ 127.705436] ---[ fin de seguimiento 0000000000000000 ]--- La razón es que el diseño de la pila para construir el argumento para ftrace_return_to_handler en return_to_handler no coincide con la estructura __arch_ftrace_regs de riscv, lo que genera resultados inesperados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/9p: corregir la desreferencia de puntero NULL en mkdir Cuando se montaba un árbol 9p con la opción 'posixacl', el directorio padre tenía una ACL predeterminada establecida para sus subdirectorios, p. ej.: setfacl -m default:group:simpsons:rwx parentdir luego, la creación de un subdirectorio hacía que el cliente 9p se bloqueara, ya que la llamada v9fs_fid_add() en la función v9fs_vfs_mkdir_dotl() establece el puntero 'fid' pasado en NULL (desde dafbe689736) aunque la llamada v9fs_set_create_acl() posterior espera un puntero 'fid' no NULL válido: [ 37.273191] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 ... [ 37.322338] Rastreo de llamadas: [ 37.323043] [ 37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714) [ 37.325532] ? search_module_extables (kernel/module/main.c:3733) [ 37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.328006] ? search_bpf_extables (kernel/bpf/core.c:804) [ 37.329142] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574) [ 37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p [ 37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p [ 37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p [ 37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p [ 37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p [ 37.338590] vfs_mkdir (fs/namei.c:4313) [ 37.339535] do_mkdirat (fs/namei.c:4336) [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354) [ 37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) [ 37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Solucione esto simplemente intercambiando la secuencia de estas dos llamadas en v9fs_vfs_mkdir_dotl(), es decir, llamando a v9fs_set_create_acl() antes v9fs_fid_add().

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.