Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de tarea bloqueada en ext4_xattr_delete_inode. Syzbot informó de un problema de tarea bloqueada: =================================================================== INFORMACIÓN: La tarea syz-executor232:5073 se bloqueó durante más de 143 segundos. No contaminada. 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:syz-exec232 estado:D pila:21024 pid:5073 ppid:5072 indicadores:0x00004004 Rastreo de llamadas: context_switch kernel/sched/core.c:5244 [en línea] __schedule+0x995/0xe20 kernel/sched/core.c:6555 schedule+0xcb/0x190 kernel/sched/core.c:6631 __wait_on_freeing_inode fs/inode.c:2196 [en línea] find_inode_fast+0x35a/0x4c0 fs/inode.c:950 iget_locked+0xb1/0x830 fs/inode.c:1273 __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861 ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389 ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148 ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880 ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296 evict+0x2a4/0x620 fs/inode.c:664 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c:5516 [en línea] ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [en línea] __do_sys_mount fs/namespace.c:3697 [en línea] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa5406fd5ea RSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea RDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970 RBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432 R10: 0000000000804a03 R11: 0000000000000202 R12: 000000000000004 R13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 000000000000000 == ... Para resolver este problema, solo necesitamos verificar si el ino del inodo EA y el padre es el mismo antes de obtener el inodo EA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrección de UaF en el apagado del oyente Como informó Christoph después de haber refactorizado la inicialización del socket pasivo, la ruta de apagado del oyente mptcp es propensa a un problema de UaF. ERROR: KASAN: use-after-free en _raw_spin_lock_bh+0x73/0xe0 Escritura de tamaño 4 en la dirección ffff88810cb23098 por la tarea syz-executor731/1266 CPU: 1 PID: 1266 Comm: syz-executor731 No contaminado 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 kasan_check_range+0x14a/0x1a0 _raw_spin_lock_bh+0x73/0xe0 subflow_error_report+0x6d/0x110 sk_error_report+0x3b/0x190 tcp_disconnect+0x138c/0x1aa0 inet_child_forget+0x6f/0x2e0 inet_csk_listen_stop+0x209/0x1060 __mptcp_close_ssk+0x52d/0x610 mptcp_destroy_common+0x165/0x640 mptcp_destroy+0x13/0x80 __mptcp_destroy_sock+0xe7/0x270 __mptcp_close+0x70e/0x9b0 mptcp_close+0x2b/0x150 inet_release+0xe9/0x1f0 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc puede expirar legítimamente entre el último recuento de referencias introducido en mptcp_subflow_queue_clean() y el acceso eventual posterior en inet_csk_listen_stop(). Tras la actualización anterior, ya no necesitamos la limpieza de sockets del receptor MSK con casos especiales: el trabajador de mptcp procesará cada uno de los sockets MSK no aceptados. Simplemente elimine el código innecesario. Tenga en cuenta que esta confirmación depende de las dos principales: mptcp: refactorizar la inicialización pasiva de sockets. mptcp: usar la cola de trabajo para eliminar los sockets no aceptados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/active: Arregla el mal uso de barreras no inactivas como rastreadores de vallas Los usuarios informaron errores en las corrupciones de listas al usar i915 perf con varias aplicaciones gráficas que se ejecutan simultáneamente. El análisis de la causa raíz apuntó a un problema en el código de procesamiento de barreras: una ejecución entre la apertura/cierre de perf que reemplaza las barreras activas con solicitudes de perf en el contexto del kernel y las operaciones de preasignación/adquisición de barreras simultáneas realizadas durante el primer pin/último desanclaje del contexto del usuario. Al agregar una solicitud a un rastreador compuesto, intentamos reutilizar un rastreador de vallas existente, ya asignado y registrado con ese compuesto. El rastreador que obtenemos puede que ya rastree otra valla, puede ser una barrera inactiva o una barrera activa. Si el rastreador que obtenemos ocurre con una barrera no inactiva, entonces intentamos eliminar esa barrera de una lista de tareas de barrera a la que pertenece. Sin embargo, mientras hacemos eso no respetamos el valor de retorno de una función que realiza la eliminación de la barrera. Si la eliminación falla, terminaríamos reutilizando el rastreador aún registrado como tarea de barrera. Dado que el mismo campo de estructura se reutiliza tanto con las listas de devolución de llamadas de valla como con la lista de tareas de barrera, es probable que se produzcan daños en la lista. Ahora, las barreras se eliminan de una lista de tareas de barrera eliminando temporalmente su contenido, recorriéndolo con la omisión del nodo que se va a eliminar y, a continuación, rellenando la lista con el contenido modificado. Si estos intentos de eliminación concurrentes, intencionalmente agresivos, no se serializan, uno o más de ellos podrían fallar debido a que la lista está temporalmente vacía. El código relacionado que ignora los resultados de la eliminación de barrera se introdujo inicialmente en la versión 5.4 mediante el commit d8af05ff38ae ("drm/i915: Permitir compartir la barrera inactiva con otras solicitudes del kernel"). Sin embargo, todos los usuarios de la rutina de eliminación de barrera aparentemente estaban serializados en ese momento, por lo que el problema no se manifestó. Los resultados de git bisect con la ayuda de una prueba IGT igt@gem_barrier_race@remote-request recientemente desarrollada indican que podrían aparecer corrupciones en la lista después deel commit 311770173fac ("drm/i915/gt: Retirada de solicitud de programación cuando la línea de tiempo está inactiva"), introducida en la v5.5. Respetar los resultados de los intentos de eliminación de barreras: marcar la barrera como inactiva solo si se elimina correctamente de la lista. Luego, antes de configurar nuestra barrera como la que se rastrea actualmente, asegurarse de que el rastreador que tenemos no sea una barrera no inactiva. Si la comprobación falla, no usar ese rastreador, sino volver atrás e intentar obtener uno nuevo y utilizable. v3: usar Unlikely() para documentar el resultado esperado (Andi). Corregir errores gramaticales en la descripción de la confirmación. v2: sin cambios de código, - culpar a el commit 311770173fac ("drm/i915/gt: Programar el retiro de solicitudes cuando la línea de tiempo está inactiva"), v5.5, no confirmar d8af05ff38ae ("drm/i915: Permitir compartir la barrera de inactividad con otras solicitudes del kernel"), v5.4, - reformular la descripción deel commit. (Seleccionado de la confirmación 506006055769b10d1b2b4e22f636f3b45e0e9fc7)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: connac: no verifique el estado de WED para dispositivos que no sean mmio WED solo es compatible con dispositivos mmio, por lo que no lo verifique para dispositivos usb o sdio. Este parche corrige el fallo informado a continuación: [ 21.946627] wlp0s3u1i3: autenticar con c4:41:1e:f5:2b:1d [ 22.525298] wlp0s3u1i3: enviar autenticación a c4:41:1e:f5:2b:1d (intentar 1/3) [ 22.548274] wlp0s3u1i3: autenticar con c4:41:1e:f5:2b:1d [ 22.557694] wlp0s3u1i3: enviar autenticación a c4:41:1e:f5:2b:1d (intentar 1/3) [ 22.565885] wlp0s3u1i3: autenticado [ 22.569502] wlp0s3u1i3: asociar con c4:41:1e:f5:2b:1d (try 1/3) [ 22.578966] wlp0s3u1i3: RX AssocResp de c4:41:1e:f5:2b:1d (capab=0x11 status=30 aid=3) [ 22.579113] wlp0s3u1i3: c4:41:1e:f5:2b:1d rechazó la asociación temporalmente; duración del regreso 1000 TU (1024 ms) [ 23.649518] wlp0s3u1i3: asociado con c4:41:1e:f5:2b:1d (intento 2/3) [ 23.752528] wlp0s3u1i3: RX AssocResp de c4:41:1e:f5:2b:1d (capab=0x11 status=0 aid=3) [ 23.797450] wlp0s3u1i3: asociado [ 24.959527] el kernel intentó ejecutar página protegida por NX - ¿intento de explotación? (uid: 0) [24.959640] ERROR: no se puede manejar el error de página para la dirección: ffff88800c223200 [24.959706] #PF: obtención de instrucción de supervisor en modo kernel [24.959788] #PF: error_code(0x0011) - violación de permisos [24.959846] PGD 2c01067 P4D 2c01067 PUD 2c02067 PMD c2a8063 PTE 800000000c223163 [24.959957] Oops: 0011 [#1] PREEMPT SMP [24.960009] CPU: 0 PID: 391 Comm: wpa_supplicant No contaminado 6.2.0-kvm #18 [ 24.960089] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 01/04/2014 [ 24.960191] RIP: 0010:0xffff88800c223200 [ 24.960446] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282 [ 24.960513] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058 [ 24.960598] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010 [ 24.960682] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c [ 24.960766] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 000000000000001 [ 24.960853] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644 [24.960950] FS: 00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 [24.961036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [24.961106] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0 [24.961190] Rastreo de llamadas: [24.961219] [ 24.961245] ? mt76_connac_mcu_add_key+0x2cf/0x310 [ 24.961313] ? mt7921_set_key+0x150/0x200 [ 24.961365] ? drv_set_key+0xa9/0x1b0 [ 24.961418] ? ieee80211_key_enable_hw_accel+0xd9/0x240 [ 24.961485] ? ieee80211_key_replace+0x3f3/0x730 [ 24.961541] ? crypto_shash_setkey+0x89/0xd0 [ 24.961597] ? ieee80211_key_link+0x2d7/0x3a0 [ 24.961664] ? crypto_aead_setauthsize+0x31/0x50 [ 24.961730] ? sta_info_hash_lookup+0xa6/0xf0 [ 24.961785] ? ieee80211_add_key+0x1fc/0x250 [ 24.961842] ? rdev_add_key+0x41/0x140 [ 24.961882] ? nl80211_parse_key+0x6c/0x2f0 [ 24.961940] ? nl80211_new_key+0x24a/0x290 [ 24.961984] ? genl_rcv_msg+0x36c/0x3a0 [ 24.962036] ? rdev_mod_link_station+0xe0/0xe0 [ 24.962102] ? nl80211_set_key+0x410/0x410 [ 24.962143] ? nl80211_pre_doit+0x200/0x200 [ 24.962187] ? genl_bind+0xc0/0xc0 [ 24.962217] ? netlink_rcv_skb+0xaa/0xd0 [ 24.962259] ? genl_rcv+0x24/0x40 [ 24.962300] ? netlink_unicast+0x224/0x2f0 [ 24.962345] ? netlink_sendmsg+0x30b/0x3d0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962440] ? __import_iovec+0x2e/0x110 [ 24.962482] ? ___sys_sendmsg+0xbe/0xe0 [ 24.962525] ? mod_objcg_state+0x25c/0x330 [ 24.962576] ? __dentry_kill+0x19e/0x1d0 [ 24.962618] ? call_rcu+0x18f/0x270 [ 24.962660] ? __dentry_kill+0x19e/0x1d0 [ 24.962702] ? __x64_sys_sendmsg+0x70/0x90 [ 24.962744] ? do_syscall_64+0x3d/0x80 [ 24.962796] ? exit_to_user_mode_prepare+0x1b/0x70 [ 24.962852] ? entry_SYSCA ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/shmem-helper: Eliminar otro objeto errante en la ruta de error drm_gem_shmem_mmap() no posee una referencia en la ruta del código de error, lo que da como resultado que el objeto GEM shmem dma-buf se libere prematuramente y genere un use-after-free posterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: no reemplace la página en rq_pages si es una continuación de la última página la lectura de empalme llama a nfsd_splice_actor para poner las páginas que contienen datos de archivo en la matriz svc_rqst->rq_pages. Sin embargo, es posible obtener un resultado de empalme que solo tenga una página parcial al final, si (p. ej.) el sistema de archivos devuelve una lectura corta que no cubre toda la página. nfsd_splice_actor colocará la página parcial en su matriz rq_pages y retornará. Luego, más tarde, cuando se vuelva a llamar a nfsd_splice_actor, el resto de la página puede terminar llenándose. En este punto, nfsd_splice_actor colocará la página en array _again_ corrompiendo la respuesta. Si esto se repite varias veces, rq_next_page saturará el array y corromperá los campos finales: los punteros rq_respages y rq_next_page. Si ya añadimos la página al array en la última pasada, no la añadamos una segunda vez al tratar con una continuación de empalme. Esto se gestionaba correctamente en nfsd_splice_actor, pero el commit 91e23b1c3982 ("NFSD: Limpiar nfsd_splice_actor()") eliminó la comprobación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/edid: corrige pérdida de información cuando no se puede obtener el ID del panel. Asegúrese de borrar el búfer de transferencia antes de obtener el EDID para evitar filtrar datos de la losa a los registros en errores que dejan el búfer sin cambios.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Ajuste insuficiente del valor predeterminado bpf_jit_limit Hemos visto informes recientes de usuarios de AWS EKS (Kubernetes) como el siguiente: Después de actualizar los nodos EKS de v20230203 a v20230217 en nuestros clústeres EKS 1.24 después de unos días, varios de los nodos tienen contenedores atascados en el estado ContainerCreating o las sondas de actividad/preparación informan el siguiente error: Sonda de preparación con error: error de rpc: código = desconocido desc = no se pudo ejecutar en el contenedor: no se pudo iniciar el ejecutable "4a11039f730203ffc003b7[...]": OCI runtime exec failed: exec failed: cannot start container process: cannot init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524: unknown Sin embargo, no habíamos visto este problema en las AMI anteriores y El problema solo comenzó a ocurrir en la versión v20230217 (tras la actualización del kernel 5.4 a la 5.10), sin otros cambios en el clúster subyacente ni en las cargas de trabajo. Probamos las sugerencias de ese problema (sysctl net.core.bpf_jit_limit=452534528), lo que permitió crear contenedores y ejecutar sondas de inmediato. Sin embargo, después de aproximadamente un día, el problema reapareció y el valor devuelto por cat /proc/vmallocinfo | grep bpf_jit | awk '{s+=$2} END {print s}' aumentó de forma constante. Probé el árbol BPF para observar los tamaños de bpf_jit_charge_modmem y bpf_jit_uncharge_modmem, así como bpf_jit_current bajo el filtro BPF tcpdump, BPF seccomp y programas nativos (e)BPF. El comportamiento parece sensato y esperado, sin ninguna fuga de datos desde la perspectiva del servidor. El control bpf_jit_limit se añadió originalmente para evitar que las aplicaciones sin privilegios que cargaban programas BPF (por ejemplo, políticas BPF seccomp) consumieran toda la memoria del módulo mediante BPF JIT, impidiendo así la carga de módulos del kernel. El límite predeterminado se definió en 2018 y, si bien era adecuado en aquel entonces, hoy en día vemos muchos más consumidores de BPF. Ajuste el límite del pool BPF JIT de 1/4 a la mitad del espacio de memoria del módulo para reflejar mejor las necesidades actuales y evitar que más usuarios se enfrenten a problemas potencialmente difíciles de depurar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Se corrige la eliminación de las reglas de direccionamiento de las reglas de limpieza de vport mc, uc y multicast en la ruta de desmontaje cuando se produce EEH. Dado que la configuración promisc del vport (uc, mc y todas) en el firmware se restablece después de EEH, el controlador mlx5 intentará eliminar las reglas mencionadas en la ruta de inicialización. Esto provoca un fallo del kernel porque estas reglas de software ya no son válidas. Se corrige anulando estas reglas justo después de la eliminación para evitar el acceso a punteros colgantes. Rastreo de llamadas: __list_del_entry_valid+0xcc/0x100 (unreliable) tree_put_node+0xf4/0x1b0 [mlx5_core] tree_remove_node+0x30/0x70 [mlx5_core] mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core] esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core] esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core] esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core] esw_enable_vport+0x130/0x260 [mlx5_core] mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core] mlx5_device_enable_sriov+0x74/0x440 [mlx5_core] mlx5_load_one+0x114c/0x1550 [mlx5_core] mlx5_pci_resume+0x68/0xf0 [mlx5_core] eeh_report_resume+0x1a4/0x230 eeh_pe_dev_traverse+0x98/0x170 eeh_handle_normal_event+0x3e4/0x640 eeh_handle_event+0x4c/0x370 eeh_event_handler+0x14c/0x210 kthread+0x168/0x1b0 ret_from_kernel_thread+0x5c/0x84

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_dh_alua: Se corrige la fuga de memoria para 'qdata' en alua_activate(). Si alua_rtpg_queue() falla desde alua_activate(), entonces 'qdata' no se libera, lo que causará la siguiente fuga de memoria: objeto sin referencia 0xffff88810b2c6980 (tamaño 32): comm "kworker/u16:2", pid 635322, jiffies 4355801099 (edad 1216426.076s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. backtrace: [<0000000098f3a26d>] alua_activate+0xb0/0x320 [<000000003b529641>] scsi_dh_activate+0xb2/0x140 [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath] [<000000007adc9ace>] process_one_work+0x3c5/0x730 [<00000000c457a985>] worker_thread+0x93/0x650 [<00000000cb80e628>] kthread+0x1ba/0x210 [<00000000a1e61077>] ret_from_fork+0x22/0x30 Solucione el problema liberando 'qdata' en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corregir desplazamiento fuera de los límites en CalculateVMAndRowBytes [POR QUÉ] Cuando PTEBufferSizeInRequests es cero, UBSAN informa la siguiente advertencia porque dml_log2 devuelve un valor negativo inesperado: el exponente de desplazamiento 4294966273 es demasiado grande para el tipo de 32 bits 'int' [CÓMO] En el caso de que PTEBufferSizeInRequests sea cero, omita dml_log2() y asigne el resultado directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Se corrige el acceso a direcciones no válidas en lookup_rec() cuando el índice es 0 KASAN informó el siguiente problema: BUG: KASAN: use-after-free en lookup_rec Lectura de tamaño 8 en la dirección ffff000199270ff0 por la tarea modprobe CPU: 2 Comm: modprobe Rastreo de llamadas: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe Al verificar pg->records[pg->index - 1].ip en lookup_rec(), puede obtener un pg que se agregó recientemente a ftrace_pages_start en ftrace_process_locs(). Antes del primer pg->index++, el índice es 0 y acceder a pg->records[-1].ip causará este problema. No verifique la IP cuando pg->index sea 0.