Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hfi1: Se corrige el error de use-after-free para la estructura mm En determinadas condiciones, como MPI_Abort, el código de limpieza hfi1 puede representar la última referencia retenida en la tarea mm. Luego, hfi1_mmu_rb_unregister() elimina la última referencia y la mm se libera antes del uso final en hfi1_release_user_pages(). Una nueva tarea puede asignar la estructura mm mientras aún se está utilizando, lo que genera problemas. Una manifestación es la corrupción del contador mmap_sem que provoca un bloqueo en down_write(). Otra es la corrupción de una estructura mm que está en uso por otra tarea.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: desbordamiento de búfer potencial al manejar enlaces simbólicos Smatch imprimió una advertencia: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' demasiado pequeño (16 vs u32max) Esto se debe a que Smatch marca 'link_len' como no confiable ya que proviene de sscanf(). Agregue una verificación para asegurarse de que 'link_len' no sea más grande que el tamaño del búfer 'link_str'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: nci: agregar flush_workqueue para evitar uaf Nuestro detector encontró un error de uso simultáneo después de la liberación al desconectar un dispositivo NCI. La razón principal de este error es la programación inesperada entre el mecanismo de retraso utilizado (temporizador y cola de trabajo). La ejecución se puede demostrar a continuación: Hilo-1 Hilo-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work) nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] | ... | Trabajador nci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2] En resumen, la rutina de limpieza pensó que el cmd_timer ya había sido separado por [1] pero el mod_timer puede volver a unir el temporizador [2], incluso si ya está liberado [3], lo que da como resultado UAF. Este UAF es fácil de activar, el seguimiento de fallas por POC es como el siguiente [66.703713] ======================================================================= [66.703974] ERROR: KASAN: use-after-free en enqueue_timer+0x448/0x490 [66.703974] Escritura de tamaño 8 en la dirección ffff888009fb7058 por la tarea kworker/u4:1/33 [66.703974] [66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 No contaminado 5.18.0-rc2 #5 [ 66.703974] Cola de trabajo: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Rastreo de llamadas: [ 66.703974] [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] [ 66.703974] [ 66.703974] Asignado por la tarea 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] Liberado por la tarea 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: Se ha corregido la desreferencia de puntero NULL en smc_pnet_find_ib(). Se llamaba a dev_name() con dev.parent como argumento, pero sin comprobarlo antes. Se soluciona comprobando el puntero antes de llamar a dev_name().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: stmmac: corregir la función altr_tse_pcs al usar un enlace fijo Al usar un enlace fijo, el controlador altr_tse_pcs se bloquea debido a la desreferencia de puntero nulo ya que no se proporciona ningún phy_device a la función tse_pcs_fix_mac_speed. Solucione esto agregando una verificación para phy_dev antes de llamar a la función tse_pcs_fix_mac_speed(). También limpie un poco la función tse_pcs_fix_mac_speed. No es necesario verificar splitter_base y sgmii_adapter_base porque el controlador fallará si estas 2 variables no se derivan del árbol de dispositivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: corrige el error KASAN slab-out-of-bounds en cachefiles_set_volume_xattr. Usa la longitud real de los datos de coherencia del volumen al configurar xattr para evitar el siguiente informe KASAN. ERROR: KASAN: slab-out-of-bounds en cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] Escritura de tamaño 4 en la dirección ffff888101e02af4 por la tarea kworker/6:0/1347 CPU: 6 PID: 1347 Comm: kworker/6:0 Kdump: cargado No contaminado 5.18.0-rc1-nfs-fscache-netfs+ #13 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014 Cola de trabajo: eventos fscache_create_volume_work [fscache] Seguimiento de llamadas: dump_stack_lvl+0x45/0x5a print_report.cold+0x5e/0x5db ? __lock_text_start+0x8/0x8 ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] kasan_report+0xab/0x120 ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] kasan_check_range+0xf5/0x1d0 memcpy+0x39/0x60 cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] cachefiles_acquire_volume+0x2be/0x500 [cachefiles] ? __cachefiles_free_volume+0x90/0x90 [cachefiles] fscache_create_volume_work+0x68/0x160 [fscache] process_one_work+0x3b7/0x6a0 worker_thread+0x2c4/0x650 ? process_one_work+0x6a0/0x6a0 kthread+0x16c/0x1a0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Asignado por la tarea 1347: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 cachefiles_set_volume_xattr+0x76/0x350 [archivos de caché] cachefiles_acquire_volume+0x2be/0x500 [archivos de caché] fscache_create_volume_work+0x68/0x160 [fscache] process_one_work+0x3b7/0x6a0 worker_thread+0x2c4/0x650 kthread+0x16c/0x1a0 ret_from_fork+0x22/0x30 La dirección con errores pertenece a el objeto en ffff888101e02af0 que pertenece al caché kmalloc-8 de tamaño 8 La dirección con errores se encuentra 4 bytes dentro de la región de 8 bytes [ffff888101e02af0, ffff888101e02af8) La dirección con errores pertenece a la página física: page:00000000a2292d70 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x101e02 flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0000200 0000000000000000 dead000000000001 ffff888100042280 raw: 0000000000000000 0000000080660066 00000001ffffffff 00000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección con errores: ffff888101e02980: FC 00 FC FC FC FC 00 FC FC FC FC 00 FC FC FC FC ffff888101e02a00: 00 FC FC FC FC 00 FC FC FC FC 00 FC FC FC FC 00 >ffff888101e02a80: FC FC FC FC 00 FC FC fc fc 00 fc fc fc fc 04 fc ^ ffff888101e02b00: fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc ffff888101e02b80: fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc =====================================================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: desmarcar inodo en uso en ruta de error Desmarcar inodo en uso si se encuentra un error. Si la fuga de la bandera en uso ocurre en cachefiles_open_file(), Cachefiles mostrará el mensaje "Inodo ya en uso" cuando más tarde se busque otra cookie con la misma clave de índice. Si la fuga de la bandera en uso ocurre en cachefiles_create_tmpfile(), aunque no se active la advertencia "Inodo ya en uso", solucione la fuga de todos modos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: Arreglar la clase de seguimiento svc_deferred_event Arreglar un fallo de desreferencia NULL que ocurre cuando se aplaza un svc_rqst mientras el subsistema de seguimiento sunrpc está habilitado. svc_revisit() establece dr->xprt en NULL, por lo que no se puede confiar en él en el punto de seguimiento para proporcionar la dirección del control remoto. Desafortunadamente, no podemos revertir el trozo "svc_deferred_class" en el commit ece200ddd54b ("sunrpc: Guardar la dirección de presentación remota en svc_xprt para eventos de seguimiento") porque ahora hay una comprobación específica de especificadores de formato de evento para desreferencias inseguras. La advertencia que emite la comprobación es: el evento svc_defer_recv tiene una desreferencia insegura del argumento 1 Un especificador de formato "%pISpc" con un "struct sockaddr *" está marcado por esta comprobación. En su lugar, adopte el enfoque de fuerza bruta utilizado por el punto de seguimiento svcrdma_qp_error. Convierta el campo dr::addr en una dirección de presentación en el brazo TP_fast_assign() del evento de seguimiento y almacénelo como una cadena. Esta corrección se puede implementar en kernels estables. Mientras tanto, el commit c6ced22997ad ("seguimiento: Actualizar la comprobación de impresión fmt para manejar la nueva macro __get_sockaddr()") ahora está en v5.18, por lo que esta corrección complicada se puede reemplazar con __sockaddr() y similares correctamente durante la ventana de fusión de v5.19.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: veth: Asegurarse de que el encabezado eth esté en la parte lineal de skb Después de alimentar un paquete desencapsulado a un dispositivo veth con act_mirred, skb_headlen() puede ser 0. Pero veth_xmit() llama a __dev_forward_skb(), que espera al menos ETH_HLEN bytes de datos lineales (como __dev_forward_skb2() llama a eth_type_trans(), que extrae ETH_HLEN bytes incondicionalmente). Utilice pskb_may_pull() para asegurarse de que veth_xmit() respete esta restricción. ¡ERROR del kernel en include/linux/skbuff.h:2328! RIP: 0010:eth_type_trans+0xcf/0x140 Rastreo de llamadas: __dev_forward_skb2+0xe3/0x160 veth_xmit+0x6e/0x250 [veth] dev_hard_start_xmit+0xc7/0x200 __dev_queue_xmit+0x47f/0x520 ? skb_ensure_writable+0x85/0xa0 ? skb_mpls_pop+0x98/0x1c0 tcf_mirred_act+0x442/0x47e [act_mirred] tcf_action_exec+0x86/0x140 fl_classify+0x1d8/0x1e0 [cls_flower] ? skb_copy_bits+0x11a/0x220 __tcf_classify+0x58/0x110 tcf_classify_ingress+0x6b/0x140 __netif_receive_skb_core.constprop.0+0x47d/0xfd0 ? __iommu_dma_unmap_swiotlb+0x44/0x90 __netif_receive_skb_one_core+0x3d/0xa0 netif_receive_skb+0x116/0x170 be_process_rx+0x22f/0x330 [be2net] be_poll+0x13c/0x370 [be2net] __napi_poll+0x2a/0x170 net_rx_action+0x22f/0x2f0 __do_softirq+0xca/0x2a8 __irq_exit_rcu+0xc1/0xe0 common_interrupt+0x83/0xa0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc: Arreglar virt_addr_valid() para Book3E de 64 bits y mpe de 32 bits: En Book3E de 64 bits, el espacio vmalloc comienza en 0x8000000000000000. Debido a la forma en que funciona __pa() tenemos: __pa(0x8000000000000000) == 0, y por lo tanto virt_to_pfn(0x8000000000000000) == 0, y por lo tanto virt_addr_valid(0x8000000000000000) == true Lo cual es incorrecto, virt_addr_valid() debería ser falso para el espacio vmalloc. De hecho, todas las direcciones vmalloc que tengan un alias con un PFN válido devolverán verdadero desde virt_addr_valid(). Esto puede causar errores con usercopy reforzado como lo describe a continuación Kefeng Wang: Al ejecutar ethtool eth0 en Book3E de 64 bits, ocurrió un ERROR: usercopy: ¡Intento de exposición de memoria del kernel detectado desde un objeto SLUB que no está en la página SLUB! (desplazamiento 0, tamaño 1048). ERROR del kernel en mm/usercopy.c:99 ... usercopy_abort+0x64/0xa0 (no confiable) __check_heap_object+0x168/0x190 __check_object_size+0x1a0/0x200 dev_ethtool+0x2494/0x2b20 dev_ioctl+0x5d0/0x770 sock_do_ioctl+0xf0/0x1d0 sock_ioctl+0x3ec/0x5a0 __se_sys_ioctl+0xf0/0x160 system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 El código se muestra a continuación, data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN)); copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) Los datos se asignan mediante vmalloc(), virt_addr_valid(ptr) devolverá verdadero en Book3E de 64 bits, lo que genera el pánico. Como lo hace el commit 4dd7554a6456 ("powerpc/64: Agregar comprobaciones VIRTUAL_BUG_ON para direcciones __va y __pa"), asegúrese de que la dirección virt sea superior a PAGE_OFFSET en virt_addr_valid() para 64 bits, y agregue también una comprobación de límite superior para asegurarse de que la dirección virt esté por debajo de high_memory. Mientras tanto, para 32 bits PAGE_OFFSET es la dirección virtual del inicio de lowmem, high_memory es la dirección virtual baja superior, la comprobación es adecuada para 32 bits, esto solucionará también el problema mencionado en el commit 602946ec2f90 ("powerpc: Set max_mapnr properly"). En 32 bits hay un problema similar con la memoria alta, que se solucionó en el commit 602946ec2f90 ("powerpc: Set max_mapnr properly"), pero ese commit rompe highmem y necesita ser revertido. No podemos arreglar fácilmente __pa(), tenemos código que depende de su comportamiento actual. Así que por ahora agregue comprobaciones adicionales a virt_addr_valid(). Para Book3S de 64 bits las comprobaciones adicionales no son necesarias, la combinación de virt_to_pfn() y pfn_valid() debería producir el resultado correcto, pero son inofensivas. [mpe: Agregar detalles adicionales del registro de cambios]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: arfs: corregir use-after-free al liberar @rx_cpu_rmap Los bots de prueba de CI activaron el siguiente splat: [ 718.203054] ERROR: KASAN: use-after-free en free_irq_cpu_rmap+0x53/0x80 [ 718.206349] Lectura de tamaño 4 en la dirección ffff8881bd127e00 por la tarea sh/20834 [ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: cargado Tainted: GSW IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1 [ 718.219695] Hardware nombre: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020 [ 718.223418] Seguimiento de llamadas: [ 718.227139] [ 718.230783] dump_stack_lvl+0x33/0x42 [ 718.234431] print_address_description.constprop.9+0x21/0x170 [ 718.238177] ? free_irq_cpu_rmap+0x53/0x80 [ 718.241885] ? informe_kasan.cold.18+0x7f/0x11b [ 718.249197] ? free_irq_cpu_rmap+0x53/0x80 [ 718.252852] free_irq_cpu_rmap+0x53/0x80 [ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [hielo] [ 718.260174] ice_remove_arfs+0x5f/0x70 [hielo] [ 718.263810] ice_rebuild_arfs+0x3b/0x70 [hielo] [ 718.267419] ice_rebuild+0x39c/0xb60 [hielo] [ 718.270974] ? preempt_count_sub+0x14/0xc0 [ 718.284984] ? delay_tsc+0x8f/0xb0 [ 718.288463] ice_do_reset+0x92/0xf0 [ice] [ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice] [ 718.295561] pci_reset_function+0x53/0x80 <...> [ 718.393035] Asignado por la tarea 690: [ 718.433497] Liberado por la tarea 20834: [ 718.495688] Última creación de trabajo potencialmente relacionada: [ 718.568966] La dirección con errores pertenece al objeto en ffff8881bd127e00 que pertenece a la caché kmalloc-96 de tamaño 96 [ 718.574085] La dirección con errores se encuentra a 0 bytes dentro de la región de 96 bytes [ffff8881bd127e00, ffff8881bd127e60) [ 718.579265] La dirección con errores pertenece a la página: [ 718.598905] Estado de la memoria alrededor de la dirección con errores: [ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc [ 718.607794] >ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.610811] ^ [ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc Esto se debe a que free_irq_cpu_rmap() siempre se llama *después* de (devm_)free_irq() y, por lo tanto, intenta funcionar. con descripciones IRQ ya liberadas. Por ejemplo, al reiniciar el dispositivo, el controlador libera el rmap justo antes de asignar uno nuevo (el símbolo de arriba). Haga que la creación y liberación de rmap sean simétricas con las llamadas {request,free}_irq(), es decir, hágalo en ifup/ifdown en lugar de en la prueba/eliminación/reanudación del dispositivo. Estas operaciones se pueden realizar independientemente de la configuración aRFS del dispositivo real. Además, asegúrese de que ice_vsi_free_irq() borre los notificadores de afinidad IRQ solo cuando aRFS esté deshabilitado; de lo contrario, el rmap de la CPU establece y borra los suyos propios y no se deben tocar manualmente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: se corrige el pánico al reenviar un paquete sin un dev in6 kongweibin informó un pánico del kernel en ip6_forward() cuando la interfaz de entrada no tiene un dev in6 asociado. Se utilizaron los siguientes comandos tc para reproducir este pánico: tc qdisc del dev vxlan100 root tc qdisc add dev vxlan100 root netem corrupt 5%