Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/debugfs: evita que se produzca use after free después de la eliminación de cdev. Dado que Thermal_debug_cdev_remove() no se ejecuta bajo cdev->lock, puede ejecutarse en paralelo con Thermal_debug_cdev_state_update() y puede liberar el objeto struct Thermal_debugfs utilizado por este último después de haberlo verificado con NULL. Si eso sucede, Thermal_debug_cdev_state_update() accederá a la memoria que ya ha sido liberada, lo que provocará que el kernel falle. Solucione esto usando cdev->lock en Thermal_debug_cdev_remove() alrededor de la verificación del valor de cdev->debugfs (en caso de que el mismo cdev se elimine al mismo tiempo en dos subprocesos diferentes) y se restablezca a NULL. CC :6.8+ # 6.8+

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel del tamaño de un conteo y copiamos el conteo de bytes del espacio de usuario a ese búfer. Más adelante, usamos sscanf en este búfer pero no nos aseguramos de que la cadena termine dentro del búfer, esto puede provocar una lectura OOB cuando usamos sscanf. Solucione este problema utilizando memdup_user_nul en lugar de memdup_user.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: efi/unaccepted: toque el bloqueo suave durante la aceptación de la memoria. El commit 50e782a86c98 ("efi/unaccepted: solucione los bloqueos suaves causados por la aceptación de la memoria paralela") ha liberado el bloqueo de giro para que otras CPU puedan usar la memoria. aceptación en paralelo y no activa el bloqueo suave en otras CPU. Sin embargo, el bloqueo suave se mostró de forma intermitente si la memoria del TD invitado es grande y el tiempo de espera del bloqueo suave se establece en 1 segundo: RIP: 0010:_raw_spin_unlock_irqrestore Seguimiento de llamadas:? __hrtimer_run_queues ? hrtimer_interrupt? watchdog_timer_fn? __sysvec_apic_timer_interrupt? __pfx_watchdog_timer_fn? sysvec_apic_timer_interrupt ? __hrtimer_run_queues ? hrtimer_interrupt? asm_sysvec_apic_timer_interrupt? _raw_spin_unlock_irqrestore? __sysvec_apic_timer_interrupt? sysvec_apic_timer_interrupt aceptar_memoria try_to_accept_memory do_huge_pmd_anonymous_page get_page_from_freelist __handle_mm_fault __alloc_pages __folio_alloc? __tdx_hypercall handle_mm_fault vma_alloc_folio do_user_addr_fault do_huge_pmd_anonymous_page exc_page_fault? __do_huge_pmd_anonymous_page asm_exc_page_fault __handle_mm_fault Cuando el irq local está habilitado al final de Accept_memory(), el bloqueo suave detecta que el mecanismo de vigilancia en una sola CPU no ha sido alimentado por un tiempo. Es decir, incluso otras CPU no serán bloqueadas por spinlock, la CPU actual podría apestar con el irq local deshabilitado por un tiempo, lo que perjudica no solo al nmi watchdog sino también al softlockup. Chao Gao señaló que la aceptación de la memoria podría llevar mucho tiempo y hubo un informe similar antes. Por lo tanto, para evitar cualquier detección de softlocup durante esta etapa, proporcione al softlockup una bandera para omitir la verificación del tiempo de espera al final de Accept_memory(), invocando touch_softlockup_watchdog().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xdp: use el campo flags para eliminar la ambigüedad de la redirección de transmisión Al redireccionar un paquete usando XDP, el asistente bpf_redirect_map() configurará la información del destino de redireccionamiento en la estructura bpf_redirect_info (usando el asistente __bpf_xdp_redirect_map() función), y la función xdp_do_redirect() leerá esta información después de que el programa XDP regrese y pasará el framework al destino de redireccionamiento correcto. Cuando se utiliza el indicador BPF_F_BROADCAST para realizar una redirección de multidifusión a un mapa completo, __bpf_xdp_redirect_map() establece el puntero 'mapa' en la estructura bpf_redirect_info para que apunte al mapa de destino que se va a transmitir. Y xdp_do_redirect() reacciona al valor de este puntero de mapa para decidir si se trata de una transmisión o una redirección de valor único. Sin embargo, si el mapa de destino se destruye antes de llamar a xdp_do_redirect(), el puntero del mapa se borrará (mediante bpf_clear_redirect_map()) sin esperar a que deje de ejecutarse ningún programa XDP. Esto hace que xdp_do_redirect() piense que la redirección fue a un único objetivo, pero el puntero de destino también es NULL (dado que las redirecciones de difusión no tienen un único objetivo), por lo que esto provoca un bloqueo cuando se pasa un puntero NULL a dev_map_enqueue( ). Para solucionar este problema, cambie xdp_do_redirect() para reaccionar directamente a la presencia del indicador BPF_F_BROADCAST en el valor 'flags' en la estructura bpf_redirect_info para eliminar la ambigüedad entre un redireccionamiento de destino único y de transmisión. Y solo lea el puntero del 'mapa' si la bandera de transmisión está activada, abortando si se ha borrado mientras tanto. Esto evita el bloqueo, manteniendo al mismo tiempo la limpieza atómica (basada en cmpxchg) del puntero del mapa y sin agregar más comprobaciones en la ruta rápida sin transmisión.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf, skmsg: Se corrigió la desreferencia del puntero NULL en sk_psock_skb_ingress_enqueue Se corrigieron las ejecucións de datos del puntero NULL en sk_psock_skb_ingress_enqueue() que syzbot informó [1]. [1] ERROR: KCSAN: ejecución de datos en sk_psock_drop / sk_psock_skb_ingress_enqueue escribe en 0xffff88814b3278b8 de 8 bytes por tarea 10724 en la CPU 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [en línea] 0 neto/núcleo/skmsg .c:843 sk_psock_put include/linux/skmsg.h:459 [en línea] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket. c:659 [en línea] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [en línea] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 leer en 0xffff8881 4b3278b8 de 8 bytes por tarea 10713 en la CPU 0: sk_psock_data_ready include/linux/skmsg.h:464 [en línea] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net /core/skmsg.c: 1008 [en línea] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [en línea] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 +0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x 312/ 0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [en línea] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [en línea] __se_sys_sendmsg net/socket. c:2674 [en línea] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 valor cambiado: 0xffffffff83d7feb0 -> 0x0000000000000000 editado por Kernel Concurrency Sanitizer en: CPU: 0 PID: 10713 Comm: syz-executor .4 Contaminado: GW 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 29/02/2024 Antes de esto, confirme 4cd12c6065df ("bpf, sockmap: corrija el puntero NULL dereference in sk_psock_verdict_data_ready()") arregló un puntero NULL de manera similar debido a que no hay protección de save_data_ready. Aquí hay otra persona que llama y causa el mismo problema por el mismo motivo. Entonces deberíamos protegerlo con el bloqueo de lectura sk_callback_lock porque el lado del escritor en sk_psock_drop() usa "write_lock_bh(&sk->sk_callback_lock);". Para evitar errores que podrían ocurrir en el futuro, muevo esos dos pares de candados a sk_psock_data_ready(), sugerido por John Fastabend.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: nfs: Maneja el error de rpc_proc_register() en nfs_net_init(). syzkaller informó que se activó una advertencia [0] al destruir redes inmaduras. Se llamó a rpc_proc_register() en init_nfs_fs(), pero su error se ignoró al menos desde el commit inicial 1da177e4c3f4 ("Linux-2.6.12-rc2"). Recientemente, el commit d47151b79e32 ("nfs: exponen /proc/net/sunrpc/nfs in net namespaces") convirtió los procfs a per-netns e hizo que el problema fuera más visible. Incluso cuando rpc_proc_register() falla, nfs_net_init() podría tener éxito y, por lo tanto, se llamará a nfs_net_exit() mientras se destruyen las redes. Luego, se llamará a remove_proc_entry() para un directorio proc no existente y se activará la siguiente advertencia. Manejemos el error de rpc_proc_register() correctamente en nfs_net_init(). [0]: nombre 'nfs' ADVERTENCIA: CPU: 1 PID: 1710 en fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Módulos vinculados en: CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/ 01/2014 RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Código: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 10286 RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001 RBP: 0000000000000000 R08: 00000000 00000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: 5741ff8 FS: 00007f30cfba8640(0000) GS: ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000000400 PKRU: 55555554 Llamar Seguimiento: rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438 ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170 setup_net+0x46c /0x660 net/core/net_namespace.c:372 copy_net_ns+0x244/0x590 net/core/net_namespace.c:505 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228 ksys_unshare +0x342/0x760 kernel/fork.c:3322 __do_sys_unshare kernel/fork.c:3393 [en línea] __se_sys_unshare kernel/fork.c:3391 [en línea] __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391 do_syscall_x64 arch/x86/ entrada/common.c:52 [en línea] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x7f30d0febe5d Código: ff c3 66 2e 0f 1f 84 00 00 0 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d X: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600 RBP: 00000000004bbf80 R08: 00000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: core: rechazar skb_copy(_expand) para fraglist GSO skbs Los skbs SKB_GSO_FRAGLIST no deben linealizarse; de lo contrario, dejarán de ser válidos. Devuelve NULL si dicho skb se pasa a skb_copy o skb_copy_expand, para evitar un bloqueo en una posible llamada posterior a skb_gso_segment.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nsh: restaurar skb->{protocol,data,mac_header} para el encabezado externo en nsh_gso_segment(). syzbot activó varios símbolos (ver [0] y enlaces) mediante un paquete GSO manipulado de VIRTIO_NET_HDR_GSO_UDP que superpone los siguientes protocolos: ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP NSH puede encapsular IPv4, IPv6, Ethernet, NSH y MPLS. Como el protocolo interno puede ser Ethernet, el controlador NSH GSO, nsh_gso_segment(), llama a skb_mac_gso_segment() para invocar los controladores GSO del protocolo interno. nsh_gso_segment() hace lo siguiente para el skb original antes de llamar a skb_mac_gso_segment() 1. restablecer skb->network_header 2. guardar el skb->{mac_heaeder,mac_len} original en una variable local 3. extraer el encabezado NSH 4. restablece skb- >mac_header 5. Configure skb->mac_len y skb->protocol para el protocolo interno. y hace lo siguiente para el skb segmentado 6. configurar ntohs(ETH_P_NSH) en skb->protocol 7. empujar el encabezado NSH 8. restaurar skb->mac_header 9. configurar skb->mac_header + mac_len en skb->network_header 10. restaurar skb->mac_len Hay dos problemas en 6-7 y 8-9. (a) Después de 6 y 7, skb->data apunta al encabezado NSH, por lo que el encabezado externo (ETH_P_8021AD en este caso) se elimina cuando skb se envía fuera de netdev. Además, si NSH está encapsulado por NSH + Ethernet (es decir, NSH-Ethernet-NSH), skb_pull() en el primer nsh_gso_segment() hará que skb->data apunte al medio del encabezado NSH o Ethernet externo porque el encabezado Ethernet es no arrastrado por el segundo nsh_gso_segment(). (b) Al restaurar skb->{mac_header,network_header} en 8 y 9, nsh_gso_segment() no supone que los datos en el búfer lineal se hayan desplazado. Sin embargo, udp6_ufo_fragment() podría cambiar los datos y cambiar skb->mac_header en consecuencia, como lo demuestra syzbot. Si esto sucede, incluso el skb->mac_header restaurado apunta al centro del encabezado externo. Parece que nsh_gso_segment() nunca ha funcionado con encabezados externos hasta ahora. Al final de nsh_gso_segment(), se debe restaurar el encabezado externo para el skb segmentado, en lugar del encabezado NSH. Para hacer eso, calculemos la posición del encabezado externo relativamente desde el encabezado interno y configuremos skb->{data,mac_header,protocol} correctamente. [0]: ERROR: KMSAN: valor uninit en ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [en línea] ERROR: KMSAN: valor uninit en ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [en línea] ERROR: KMSAN: valor uninit en ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [en línea] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c: 602 [en línea] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [en línea] _xmitir include/linux/netdevice.h:5003 [en línea] xmit_one net/core/dev.c:3547 [en línea] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev. c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [en línea] paquete_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 paquete_snd net/packet/af_packet.c:3081 [en línea] paquete_sendmsg+0x8aef/0x9f10 net/ paquete/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [ en línea] __se_sys_sendto net/socket.c:2199 [en línea] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry /common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en: slab_post_alloc_hook mm/slub.c:3819 [en línea] slab_alloc_node mm/slub.c:3860 [en línea] __do_kmalloc_node mm/slub.c:3980---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bna: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel de tamaño nbytes y copiamos nbytes del espacio de usuario a ese búfer. Más adelante, usamos sscanf en este búfer pero no nos aseguramos de que la cadena termine dentro del búfer, esto puede provocar una lectura OOB cuando usamos sscanf. Solucione este problema utilizando memdup_user_nul en lugar de memdup_user.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corrige el desbordamiento en blk_ioctl_discard() No hay verificación de desbordamiento de 'start + len' en blk_ioctl_discard(). La tarea bloqueada ocurre si envía un ioctl de descarte con el siguiente parámetro: start = 0x80000000000ff000, len = 0x8000000000fff000; Agregue la validación de desbordamiento ahora.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: Verificar el tamaño del valor del mapa del filtro de floración. Este parche agrega una verificación faltante para la creación del filtro de floración, rechazando valores superiores a KMALLOC_MAX_SIZE. Esto alinea el mapa de floración con muchos otros tipos de mapas. La falta de esta protección puede provocar fallas del kernel para tamaños de valores que desbordan los de int. Syzkaller captó tal accidente. El siguiente parche agrega más barandillas en un nivel inferior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: evitar escritura de extensión de campos de memcpy ADVERTENCIA Cuando se ejecuta el comando "storcli2 show" para eHBA-9600, el controlador mpi3mr imprime este mensaje de ADVERTENCIA: memcpy: extensión de campos detectada escriba (tamaño 128) de un solo campo "bsg_reply_buf->reply_buf" en drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (tamaño 1) ADVERTENCIA: CPU: 0 PID: 12760 en drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr] La causa de la ADVERTENCIA es 128 bytes de memoria en la matriz de tamaño de 1 byte "__u8 replay_buf[1]" en la estructura mpi3mr_bsg_in_reply_buf. La matriz está manipulada para ser una matriz de longitud flexible, por lo que WARN es un falso positivo. Para suprimir WARN, elimine el número constante '1' de la declaración de matriz y aclare que tiene una longitud flexible. Además, ajuste el tamaño de la asignación de memoria para que coincida con el cambio.