Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: Validar l_tree_depth para evitar accesos fuera de los límites. El campo l_tree_depth es de 16 bits (__le16), pero la profundidad máxima real está limitada a OCFS2_MAX_PATH_DEPTH. Se ha añadido una comprobación para evitar accesos fuera de los límites si l_tree_depth tiene un valor no válido, lo que puede ocurrir al leer desde un disco montado dañado [1].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se corrigen un par de desbordamientos de enteros en sistemas de 32 bits. En sistemas de 32 bits, la adición "off + sizeof(struct NTFS_DE)" puede causar un problema de ajuste de enteros. Se soluciona con size_add().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Arreglar el flujo de actualización de mlx5_poll_one() cur_qp Cuando cur_qp no es NULL, para evitar obtener el QP del árbol de radix de nuevo, verificamos si el siguiente QP de cqe es idéntico al que ya tenemos. Sin embargo, el error es que estamos verificando si el QP es idéntico al comparar el número de QP dentro del CQE con el número de QP dentro de mlx5_ib_qp, pero eso es incorrecto ya que el número de QP del CQE es de FW, por lo que debe coincidir con mlx5_core_qp, que es nuestro número de QP de FW. De lo contrario, podríamos usar el QP incorrecto al gestionar un CQE, lo que podría causar el siguiente rastreo del kernel. Este problema se nota principalmente en los QP 0 y 1, ya que por ahora son los únicos QP en nuestro controlador, mientras que el número de QP dentro de mlx5_ib_qp no coincide con el número de QP dentro de mlx5_core_qp. ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000012 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 No contaminado 6.14.0-rc3+ #189 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Cola de trabajo: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Código: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 00000000000000000 RCX: 0000000000000000 RDX: 00000000000000000 RSI: ffff88885fa1b3c0 RDI: fffffffa06e894a RBP: 00000000000000b0 R08: 00000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 00000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Seguimiento de llamadas: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vhost-scsi: Se corrige la gestión de múltiples llamadas a vhost_scsi_set_endpoint Si vhost_scsi_set_endpoint se llama varias veces sin un vhost_scsi_clear_endpoint entre ellas, podemos encontrar múltiples errores encontrados por Haoran Zhang: 1. use-after-free cuando no se encuentran tpgs: Esto corrige un use-after-free que ocurre cuando vhost_scsi_set_endpoint se llama más de una vez y las llamadas después de la primera llamada no encuentran ningún tpg para agregar al vs_tpg. Cuando vhost_scsi_set_endpoint encuentra primero tpgs para agregar a la matriz vs_tpg match=true, entonces haremos: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; Si se llama nuevamente a vhost_scsi_set_endpoint y no se encuentran tpgs, match=false, por lo que omitimos la llamada a vhost_vq_set_backend dejando el puntero al vs_tpg que luego liberamos mediante: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; Si luego se envía una solicitud scsi, hacemos: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend que ve el vs_tpg en el que acabamos de realizar un kfree. 2. Se bloquea la eliminación del directorio tpg: este parche corrige un problema por el cual no podemos eliminar un directorio tpg de capa LIO/objetivo (y estructuras por encima de él como el objetivo) debido a que el recuento de referencias cae a -1. El problema radica en que si vhost_scsi_set_endpoint detecta que ya hay un TPG en la matriz vs->vs_tpg, o si este se ha eliminado y, por lo tanto, target_depend_item falla, el controlador goto undepend ejecutará `target_undepend_item` en todos los TPG de la matriz vs_tpg, reduciendo su recuento de referencias a 0. En este momento, vs_tpg contiene tanto los TPG que hemos añadido en la llamada actual a vhost_scsi_set_endpoint como los TPG añadidos en llamadas anteriores que también están en vs->vs_tpg. Posteriormente, al ejecutarse vhost_scsi_clear_endpoint, ejecutará `target_undepend_item` en todos los TPG de vs->vs_tpg, lo que reducirá su recuento de referencias a -1. En ese caso, el espacio de usuario no podrá eliminar el TPG y se bloqueará al intentar ejecutar `rmdir` en el directorio del TPG. 3. Fuga de TPG: Esto corrige un error que permitía filtrar TPG y hacer que no se pudieran eliminar, ya que el nombre del objetivo se sobrescribía al llamar a vhost_scsi_set_endpoint varias veces, pero con nombres de objetivo diferentes. El error se produce si un usuario llama a VHOST_SCSI_SET_ENDPOINT y configura un dispositivo vhost-scsi para la asignación de destino/TPG, y luego vuelve a llamar a VHOST_SCSI_SET_ENDPOINT con un nuevo nombre de objetivo que contiene TPG desconocidos (target1 tiene TPG1, pero target2 tiene TPG2). En este caso, no se elimina la antigua asignación de TPG del objetivo, sino que se sobrescribe el nombre del objetivo y la matriz vs->vs_tpg. Posteriormente, al ejecutar vhost_scsi_clear_endpoint, se pasa el nombre de target1 o target2, y solo se coincidirán los TPG de ese objetivo al recorrer vs->vs_tpg. Luego, regresaremos de la función sin ejecutar `target_undepend_item` en los tpgs. Debido a todos estos errores, parece que nunca se permitió llamar a `vhost_scsi_set_endpoint` varias veces. El usuario principal, QEMU, ya cuenta con comprobaciones para evitar este caso de uso. Por lo tanto, para solucionar los problemas, este parche impide que se llame a `vhost_scsi_set_endpoint` si ya se han agregado correctamente los tpgs. Para agregar, eliminar o cambiar la configuración de `tpg` o el nombre del destino, primero debe ejecutar `vhost_scsi_clear_endpoint`.

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: 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: 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: 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: 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: 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.