Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virt: tdx-guest: Just leak decrypted memory on unrecoverable errors En las máquinas virtuales CoCo, es posible que el host no confiable haga que set_memory_decrypted() falle de modo que se devuelva un error y se comparta la memoria resultante. Los llamadores deben tener cuidado de gestionar estos errores para evitar devolver memoria descifrada (compartida) al asignador de páginas, lo que podría provocar problemas funcionales o de seguridad. Filtra la memoria descifrada cuando set_memory_decrypted() falla y no necesitas imprimir un error ya que set_memory_decrypted() llamará a WARN_ONCE().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: rockchip: samsung-hdptx: Establecer drvdata antes de habilitar el PM en tiempo de ejecución En algunos casos, se puede invocar rk_hdptx_phy_runtime_resume() antes de que se ejecute platform_set_drvdata() en ->probe(), lo que genera una desreferencia de puntero NULL cuando se usa el retorno de dev_get_drvdata(). Asegúrese de que se llame a platform_set_drvdata() antes de devm_pm_runtime_enable().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: comprobar el valor de retorno de sock_recvmsg al drenar datos de clc Al recibir un mensaje de clc, la longitud del campo en smc_clc_msg_hdr indica que la longitud del mensaje debe recibirse de la red y que el valor no debe ser completamente confiable ya que es de la red. Una vez que el valor de la longitud excede el valor de buflen en la función smc_clc_wait_msg, puede encontrarse con un bucle muerto al intentar drenar los datos restantes que exceden buflen. Este parche verifica el valor de retorno de sock_recvmsg al drenar datos en caso de un bucle muerto en el drenaje.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: power: supply: gpio-charger: Fix set charge current limits Fix set charge current limits for devices which allow to set the lowest charge current limit to be mayor que cero. Si el límite de corriente de carga solicitado es inferior al límite inferior, el índice es igual a current_limit_map_size, lo que provoca el acceso a la memoria más allá de la memoria asignada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/dp_mst: garantizar que el puntero mst_primary sea válido en drm_dp_mst_handle_up_req() Al recibir un mensaje de solicitud de activación de MST de un hilo en drm_dp_mst_handle_up_req(), la topología de MST podría eliminarse de otro hilo mediante drm_dp_mst_topology_mgr_set_mst(false), liberando mst_primary y estableciendo drm_dp_mst_topology_mgr::mst_primary en NULL. Esto podría conducir a una desreferencia/use after free de NULL de mst_primary en drm_dp_mst_handle_up_req(). Evite lo anterior manteniendo una referencia para mst_primary en drm_dp_mst_handle_up_req() mientras se usa. v2: Se soluciona el problema de liberar la solicitud si falla la obtención de una referencia mst_primary.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ring-buffer: Corregir desbordamiento en __rb_map_vma Se produjo un desbordamiento al realizar el siguiente cálculo: nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; Agregue una verificación antes del cálculo para evitar este problema. syzbot reportó esto como un slab-out-of-bounds en __rb_map_vma: ERROR: KASAN: slab-out-of-bounds en __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058 Lectura de tamaño 8 en la dirección ffff8880767dd2b8 por la tarea syz-executor187/5836 CPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 No contaminado 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/11/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 imprimir_dirección_descripción mm/kasan/report.c:378 [en línea] imprimir_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058 mapa_de_buffer_de_anillo+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138 rastreo_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482 llamada_mmap include/linux/fs.h:2183 [en línea] archivo_mmap mm/internal.h:124 [en línea] __mmap_nuevo_archivo_vma mm/vma.c:2291 [en línea] __mmap_nuevo_vma mm/vma.c:2355 [en línea] __mmap_region+0x1786/0x2670 mm/vma.c:2456 mmap_region+0x127/0x320 mm/mmap.c:1348 do_mmap+0xc00/0xfc0 mm/mmap.c:496 vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580 ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [en línea] __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [en línea] __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f El reproductor de este error es: ------------------------8<-------------------------- #include #include #include #include #include int main(int argc, char **argv) { int tamaño_página = getpagesize(); int fd; void *meta; system("echo 1 > /sys/kernel/tracing/buffer_size_kb"); fd = open("/sys/kernel/tracing/per_cpu/cpu0/trace_pipe_raw", O_RDONLY); meta = mmap(NULL, tamaño_página, PROT_READ, MAP_SHARED, fd, tamaño_página * 5); } ------------------------>8-------------------------

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tun: fix tun_napi_alloc_frags() syzbot informó del siguiente fallo [1] El problema surgió con la confirmación criticada. En lugar de pasar por todos los componentes de iov, seguimos usando el primero y terminamos con un skb mal formado. [1] ¡ERROR del kernel en net/core/skbuff.c:2849! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 6230 Comm: syz-executor132 No contaminado 6.13.0-rc1-syzkaller-00407-g96b6fcc0ee41 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/11/2024 RIP: 0010:__pskb_pull_tail+0x1568/0x1570 net/core/skbuff.c:2848 Código: 38 c1 0f 8c 32 f1 ff ff 4c 89 f7 e8 92 96 74 f8 e9 25 f1 ff ff e8 e8 ae 09 f8 48 8b 5c 24 08 e9 eb fb ff ff e8 d9 ae 09 f8 90 <0f> 0b 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffc90004cbef30 EFLAGS: 00010293 RAX: ffffffff8995c347 RBX: 00000000ffffff2 RCX: ffff88802cf45a00 RDX: 000000000000000 RSI: 00000000ffffff2 RDI: 000000000000000 RBP: ffff88807df0c06a R08: ffffffff8995b084 R09: 1ffff1100fbe185c R10: dffffc0000000000 R11: ffffed100fbe185d R12: ffff888076e85d50 R13: ffff888076e85c80 R14: ffff888076e85cf4 R15: ffff888076e85c80 FS: 00007f0dca6ea6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0dca6ead58 CR3: 00000000119da000 CR4: 000000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: skb_cow_data+0x2da/0xcb0 net/core/skbuff.c:5284 tipc_aead_decrypt net/tipc/crypto.c:894 [en línea] tipc_crypto_rcv+0x402/0x24e0 net/tipc/crypto.c:1844 tipc_rcv+0x57e/0x12a0 net/tipc/node.c:2109 tipc_l2_rcv_msg+0x2bd/0x450 net/tipc/bearer.c:668 __netif_receive_skb_list_ptype net/core/dev.c:5720 [en línea] __netif_receive_skb_list_core+0x8b7/0x980 net/core/dev.c:5762 __netif_receive_skb_list net/core/dev.c:5814 [en línea] netif_receive_skb_list_internal+0xa51/0xe30 net/core/dev.c:5905 gro_normal_list include/net/gro.h:515 [en línea] napi_complete_done+0x2b5/0x870 net/core/dev.c:6256 napi_complete include/linux/netdevice.h:567 [en línea] tun_get_user+0x2ea0/0x4890 drivers/net/tun.c:1982 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2057 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 fs/read_write.c:1050 do_writev+0x1b6/0x360 fs/lectura_escritura.c:1096 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Juega bien con invitados protegidos en complete_hypercall_exit() Usa is_64_bit_hypercall() en lugar de is_64_bit_mode() para detectar una hiperllamada de 64 bits al completar dicha hiperllamada. Para invitados con estado protegido, por ejemplo, SEV-ES y SEV-SNP, KVM debe asumir que la hiperllamada se realizó en modo de 64 bits, ya que el estado de vCPU necesario para detectar el modo de 64 bits no está disponible. Al piratear la autoprueba sev_smoke_test para generar una hiperllamada KVM_HC_MAP_GPA_RANGE a través de VMGEXIT se activa el WARN: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 273 PID: 326626 en arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm] Módulos vinculados en: kvm_amd kvm ... [última descarga: kvm] CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test No contaminado 6.12.0-smp--392e932fa0f3-feat #470 Nombre del hardware: Google Astoria/astoria, BIOS 0.20240617.0-0 17/06/2024 RIP: 0010:completar_hiperllamada_salida+0x44/0xe0 [kvm] Seguimiento de llamadas: kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm] kvm_vcpu_ioctl+0x54f/0x630 [kvm] __se_sys_ioctl+0x6b/0xc0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[fin del seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: util: evitar acceder a un búfer de anillo que aún no se ha inicializado Si el daemon KVP (o VSS) se inicia antes de que el búfer de anillo del canal VMBus se haya inicializado por completo, podemos activar el pánico siguiente: hv_utils: registrar el controlador de la utilidad HyperV hv_vmbus: registrar el controlador hv_utils ... ERROR: desreferencia de puntero NULL del kernel, dirección: 000000000000000 CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: GE 6.11.0-rc3+ #1 RIP: 0010:hv_pkt_iter_first+0x12/0xd0 Seguimiento de llamadas: ... vmbus_recvpacket hv_kvp_onchannelcallback vmbus_on_event tasklet_action_common asm_sysvec_hyperv_stimer0 ... kvp_register_done hvt_op_read vfs_read ksys_read __x64_sys_read Esto puede suceder porque la devolución de llamada del canal KVP/VSS se puede invocar incluso antes de que el canal esté completamente abierto: 1) tan pronto como hv_kvp_init() -> hvutil_transport_init() crea /dev/vmbus/hv_kvp, el daemon kvp puede abrir el archivo del dispositivo inmediatamente y registrarse en el controlador escribiendo un mensaje KVP_OP_REGISTER1 en el archivo (que es gestionado por kvp_on_msg() ->kvp_handle_handshake()) y leyendo el archivo para la respuesta del controlador, que es gestionada por hvt_op_read(), que llama a hvt->on_read(), es decir, kvp_register_done(). 2) El problema con kvp_register_done() es que puede provocar que se llame a la devolución de llamada del canal incluso antes de que el canal esté completamente abierto, y cuando la devolución de llamada del canal está comenzando a ejecutarse, util_probe()-> vmbus_open() puede no haber inicializado aún el ringbuffer, por lo que la devolución de llamada puede alcanzar el pánico de la desreferencia de puntero NULL. Para reproducir el pánico de manera consistente, podemos agregar un "ssleep(10)" para KVP en __vmbus_open(), justo antes del primer hv_ringbuffer_init(), y luego descargamos y volvemos a cargar el controlador hv_utils, y ejecutamos el daemon manualmente dentro de los 10 segundos. Solucione el problema reordenando los pasos en util_probe() de modo que la entrada char dev que utiliza el daemon KVP o VSS no se cree hasta que se haya completado vmbus_open(). Esta reordenación evita que se produzca la condición de ejecución.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/modes: Evite dividir por cero con más dificultad en drm_mode_vrefresh() drm_mode_vrefresh() intenta evitar dividir por cero comprobando si htotal o vtotal son cero. Pero aún así podemos terminar con una división por cero de vtotal*htotal*...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: iso: Corregir bloqueo circular en iso_listen_bis Esto corrige la advertencia de dependencia de bloqueo circular a continuación, liberando el bloqueo del socket antes de ingresar a iso_listen_bis, para evitar cualquier posible bloqueo con el bloqueo hdev. [ 75.307983] ========================================================= [ 75.307984] ADVERTENCIA: posible dependencia de bloqueo circular detectada [ 75.307985] 6.12.0-rc6+ #22 No contaminado [ 75.307987] ------------------------------------------------------ [ 75.307987] kworker/u81:2/2623 está intentando adquirir el bloqueo: [ 75.307988] ffff8fde1769da58 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO) en: iso_connect_cfm+0x253/0x840 [bluetooth] [ 75.308021] pero la tarea ya tiene el bloqueo: [ 75.308022] ffff8fdd61a10078 (&hdev->lock) en: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth] [ 75.308053] cuyo bloqueo ya depende del nuevo bloqueo. [ 75.308054] la cadena de dependencia existente (en orden inverso) es: [ 75.308055] -> #1 (&hdev->lock){+.+.}-{3:3}: [ 75.308057] __mutex_lock+0xad/0xc50 [ 75.308061] mutex_lock_nested+0x1b/0x30 [ 75.308063] iso_sock_listen+0x143/0x5c0 [bluetooth] [ 75.308085] __sys_listen_socket+0x49/0x60 [ 75.308088] __x64_sys_listen+0x4c/0x90 [ 75.308090] x64_sys_call+0x2517/0x25f0 [ 75.308092] hacer_syscall_64+0x87/0x150 [ 75.308095] entrada_SYSCALL_64_después_de_hwframe+0x76/0x7e [ 75.308098] -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}: [ 75.308100] __lock_acquire+0x155e/0x25f0 [ 75.308103] lock_acquire+0xc9/0x300 [ 75.308105] lock_sock_nested+0x32/0x90 [ 75.308107] iso_connect_cfm+0x253/0x840 [bluetooth] [ 75.308128] hci_connect_cfm+0x6c/0x190 [bluetooth] [ 75.308155] hci_le_per_adv_report_evt+0x27b/0x2f0 [bluetooth] [ 75.308180] hci_le_meta_evt+0xe7/0x200 [bluetooth] [ 75.308206] hci_event_packet+0x21f/0x5c0 [bluetooth] [ 75.308230] hci_rx_work+0x3ae/0xb10 [bluetooth] [ 75.308254] process_one_work+0x212/0x740 [ 75.308256] worker_thread+0x1bd/0x3a0 [ 75.308258] kthread+0xe4/0x120 [ 75.308259] ret_from_fork+0x44/0x70 [ 75.308261] ret_from_fork_asm+0x1a/0x30 [ 75.308263] otra información que podría ayudarnos a depurar esto: [ 75.308264] Posible escenario de bloqueo inseguro: [ 75.308264] CPU0 CPU1 [ 75.308265] ---- ---- [ 75.308265] lock(&hdev->lock); [ 75.308267] lock(sk_lock- AF_BLUETOOTH-BTPROTO_ISO); [ 75.308268] bloquear(&hdev->bloquear); [ 75.308269] bloquear(sk_lock-AF_BLUETOOTH-BTPROTO_ISO); [ 75.308270] *** BLOQUEO INTERMEDIO *** [ 75.308271] 4 bloqueos mantenidos por kworker/u81:2/2623: [ 75.308272] #0: ffff8fdd66e52148 ((wq_completion)hci0#2){+.+.}-{0:0}, en: process_one_work+0x443/0x740 [ 75.308276] #1: ffffafb488b7fe48 ((work_completion)(&hdev->rx_work)), en: process_one_work+0x1ce/0x740 [ 75.308280] #2: ffff8fdd61a10078 (&hdev->lock){+.+.}-{3:3} en: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth] [ 75.308304] #3: ffffffffb6ba4900 (rcu_read_lock){....}-{1:2}, en: hci_connect_cfm+0x29/0x190 [bluetooth]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: client: fix TCP timers deadlock after rmmod Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") corrigió un UAF de netns habilitando manualmente el recuento de referencias de sockets (sk->sk_net_refcnt=1 y sock_inuse_add(net, 1)). La razón por la que el parche funcionó para ese error fue porque ahora tenemos referencias a netns (get_net_track() obtiene una referencia internamente) y se liberan correctamente (internamente, en __sk_destruct()), pero solo porque se configuró sk->sk_net_refcnt. Problema: (esto sucede independientemente de CONFIG_NET_NS_REFCNT_TRACKER y sin importar si es init_net u otro) Establecer sk->sk_net_refcnt=1 *manualmente* y *después* de la creación del socket no solo está fuera del alcance de cifs, sino que también es técnicamente incorrecto: se establece condicionalmente en función de los sockets del usuario (=1) frente a los del kernel (=0). Y las implementaciones de net/ parecen basar sus operaciones de espacio de usuario frente a kernel en ello. p. ej., al cerrar el socket TCP, los temporizadores TCP no se borran porque sk->sk_net_refcnt=1: (cf. commit 151c9c724d05 ("tcp: finalizar correctamente los temporizadores para los sockets del kernel")) net/ipv4/tcp.c: void tcp_close(struct sock *sk, long timeout) { lock_sock(sk); __tcp_close(sk, timeout); release_sock(sk); if (!sk->sk_net_refcnt) inet_csk_clear_xmit_timers_sync(sk); sock_put(sk); } Esto arrojará una advertencia de lockdep y luego, como se esperaba, un bloqueo en tcp_write_timer(). Una forma de reproducir esto es ejecutando el reproductor desde ef7134c7fc48 y luego 'rmmod cifs'. Unos segundos más tarde, aparece la advertencia de bloqueo/lockdep. Solución: No deberíamos meternos con los componentes internos del socket nosotros mismos, así que no configure sk_net_refcnt manualmente. También cambie __sock_create() a sock_create_kern() para que sea más explícito. En cuanto a los espacios de nombres de red que no son init_net, lo tratamos de la mejor manera que podemos: mantenemos una referencia netns adicional para server->ssocket y la descartamos cuando se libera. Esto garantiza que netns siga existiendo siempre que necesitemos crear o destruir server->ssocket, pero no está directamente vinculado a él.