Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: oa_tc6: arregla la condición de ejecución de tx skb entre punteros de referencia Hay dos punteros skb para administrar los tx skb en cola desde la pila n/w. El puntero waiting_tx_skb apunta al tx skb que necesita ser procesado y el puntero progress_tx_skb apunta al tx skb que está siendo procesado. El hilo SPI prepara los fragmentos de datos de tx desde el tx skb apuntado por el puntero progress_tx_skb. Cuando se procesa el tx skb apuntado por progress_tx_skb, el tx skb apuntado por progress_tx_skb se asigna a progress_tx_skb y el puntero waiting_tx_skb se asigna con NULL. Siempre que haya un nuevo skb tx de la pila n/w, se asignará al puntero waiting_tx_skb si es NULL. Puesta en cola y procesamiento de un skb tx gestionado en dos subprocesos diferentes. Considere un escenario donde el subproceso SPI procesó un going_tx_skb y mueve el siguiente skb tx del puntero waiting_tx_skb al puntero going_tx_skb sin hacer ninguna comprobación NULL. En este momento, si el puntero waiting_tx_skb es NULL, entonces el puntero going_tx_skb también se asigna con NULL. Después de eso, si un nuevo skb tx se asigna al puntero waiting_tx_skb por la pila n/w y existe la posibilidad de sobrescribir el puntero skb tx con NULL en el subproceso SPI. Finalmente, uno de los skb tx quedará como sin gestionar, lo que resultará en la pérdida de paquetes y pérdida de memoria. - Considere el siguiente escenario donde el TXC informado de la transferencia anterior es 10 y progress_tx_skb contiene una trama Ethernet de transmisión que se puede transportar en 20 TXC y waiting_tx_skb sigue siendo NULL. tx_credits = 10; /* 21 se completan en la transferencia anterior */ progress_tx_skb = 20; waiting_tx_skb = NULL; /* Sigue siendo NULL */ - Entonces, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) se vuelve verdadero. - Después de oa_tc6_prepare_spi_tx_buf_for_tx_skbs() progress_tx_skb = 10; waiting_tx_skb = NULL; /* Sigue siendo NULL */ - Realizar transferencia SPI. - Procesar el búfer de recepción SPI para obtener el TXC de los pies de página. - Ahora supongamos que los 21 TXC previamente completados se liberan, por lo que estamos listos para transportar los siguientes 10 fragmentos de tx restantes desde progress_tx_skb. tx_credits = 21; progress_tx_skb = 10; waiting_tx_skb = NULL; - Entonces, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) se vuelve verdadero nuevamente. - En oa_tc6_prepare_spi_tx_buf_for_tx_skbs() progress_tx_skb = NULL; waiting_tx_skb = NULL; - Ahora, el siguiente caso malo podría ocurrir, Thread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler) --------------------------- ----------------------------------- - si waiting_tx_skb es NULL - si going_tx_skb es NULL - going_tx_skb = waiting_tx_skb - waiting_tx_skb = skb - waiting_tx_skb = NULL ... - going_tx_skb = NULL - si waiting_tx_skb es NULL - waiting_tx_skb = skb Para superar el problema anterior, proteja el movimiento de la referencia tx skb del puntero waiting_tx_skb al puntero going_tx_skb y asigne el nuevo tx skb al puntero waiting_tx_skb, de modo que el otro hilo no pueda acceder al puntero waiting_tx_skb hasta que el hilo actual complete el movimiento de la referencia tx skb de manera segura.

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