Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: soluciona el posible use after free en ec_bhf_remove static void ec_bhf_remove(struct pci_dev *dev) { ... struct ec_bhf_priv *priv = netdev_priv(net_dev); anular el registro_netdev(net_dev); free_netdev(net_dev); pci_iounmap(dev, priv->dma_io); pci_iounmap(dev, priv->io); ... } priv son datos privados de netdev, pero se usan después de free_netdev(). Puede causar use after free al acceder al puntero privado. Entonces, solucionelo moviendo free_netdev() después de las llamadas a pci_iounmap().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: cdc_eem: corrige la fuga de skb de reparación de tx cuando usbnet transmite un skb, eem lo repara en eem_tx_fixup(), si skb_copy_expand() falla, devuelve NULL, usbnet_start_xmit() No tendrá posibilidad de liberar el skb original. solucionelo primero con skb original gratuito en eem_tx_fixup(), luego verifique el estado del clon de skb, si falla, devuelva NULL a usbnet.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: hamradio: corrige la pérdida de memoria en mkiss_close. Mi instancia local de syzbot tuvo una pérdida de memoria en mkiss_open()[1]. El problema estaba en que faltaba free_netdev() en mkiss_close(). En mkiss_open() el dispositivo de red se asigna y luego se registra, pero en mkiss_close() el dispositivo de red solo se anula del registro, pero no se libera. Registro de errores: ERROR: pérdida de memoria, objeto sin referencia 0xffff8880281ba000 (tamaño 4096): comunicación "syz-executor.1", pid 11443, santiamén 4295046091 (edad 17,660 s) volcado hexadecimal (primeros 32 bytes): 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0............. 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*....... .... seguimiento: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x98/0xe80 [] mkiss_open+0xb2/0x6f0 [] tty_ldisc_open+0x9b/0x110 [ ] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] Entry_SYSCALL_64_after_hwframe+0x44/0xae ERROR : pérdida de memoria objeto sin referencia 0xffff8880141a9a00 (tamaño 96): comm "syz-executor.1", pid 11443, jiffies 4295046091 (edad 17.660s) volcado hexadecimal (primeros 32 bytes): e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(.... 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@....... .. seguimiento: [] __hw_addr_create_ex+0x5b/0x310 [] __hw_addr_add_ex+0x1f8/0x2b0 [] f0 [] alloc_netdev_mqs+0x13b/0xe80 [] mkiss_open +0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] Entry_SYSCALL_64_after_hwframe+0x44/0xae ERROR: pérdida de memoria objeto sin referencia 0xffff8880219bfc00 (tamaño 512): comm "syz-executor.1", pid 11443, jiffies 95046091 (edad 17.660 años) volcado hexadecimal (primeros 32 bytes): 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ...(............ 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................ rastreo inverso: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x777/0xe80 [] mkiss_open+0xb2 /0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+0x3a/0xb0 [] Entry_SYSCALL_64_after_hwframe+0x44/0xae ERROR: pérdida de memoria objeto sin referencia 0xffff888029b2b200 (tamaño 256): comm "syz-executor.1", pid 11443, jiffies 046091 (edad 17.660 años) volcado hexadecimal (primero 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ rastreo inverso: [] kvmalloc_node+0x61/0xf0 [] alloc_netdev_mqs+0x912/0xe80 [] mkiss_open+0xb2/0x6f0 [1] [] tty_ldisc_open+0x9b/0x110 [] tty_set_ldisc+0x2e8/0x670 [] tty_ioctl+0xda3/0x1440 [] __x64_sys_ioctl+0x193/0x200 [] do_syscall_64+ 0x3a/0xb0 [] entrada_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: evita un use after free cuando falla BO init nouveau_bo_init() está respaldado por ttm_bo_init() y envía su código de retorno de regreso a la persona que llama. En caso de falla, ttm_bo_init() invoca el destructor proporcionado que debería desinicializar y liberar la memoria. Por lo tanto, cuando nouveau_bo_init() devuelve un error, el objeto gema ya ha sido liberado y la memoria ha sido liberada por nouveau_bo_del_ttm().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: core: soluciona el pánico del kernel cuando se reinicia. Cuando se reinicia el sistema, llama a dwc3_shutdown y todos los debugfs para dwc3 se eliminan primero, cuando el dispositivo intenta realizar deinit. y elimina debugfs para sus endpoints, se encuentra con el problema de desreferencia del puntero NULL cuando se llama a debugfs_lookup. Solucionelo eliminando todos los debugfs de dwc3 posteriores a dwc3_drd_exit. [2924.958838] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000002 .... [2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [2925.037005] pc: inode_permission+0x2c /0x198 [ 2925.041281 ] lr: lookup_one_len_common+0xb0/0xf8 [2925.045903] sp: ffff80001276ba70 [2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000 000 [2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: muerto000000000100 [2925.063510] x23: muerto000000000122 x22: 00000000000000 00x21: 0000000000000001 [ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000 [ 2925.077797] x17: 0000000000000000 x16: 00000000 x15: 0000000000000004 [ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030 [ 2925.092087] x11: 101010101 x10: 7f7f7f7f7f7f7f7f x9: ffff8000102b2420 [2925.099232 ] x8: 7f7f7f7f7f7f7f7f x7: feff73746e2f6f64 x6: 0000000000008080 [2925.106378] x5: 61c8864680b583eb x4: 209e6ec2d263dbb7 x3: 000074756 f307065 [2925.113523] x2: 0000000000000001 x1: 0000000000000000 x0: ffff8000122c6188 [2925.120671] Seguimiento de llamada: [2925.123119] inode_permission+0x2c/0x 198 [ 2925.127042 ] lookup_one_len_common+0xb0/0xf8 [ 2925.131315] lookup_one_len_unlocked+0x34/0xb0 [ 2925.135764] lookup_positive_unlocked+0x14/0x50 [ 2925.140296] debugfs_lookup+0x68/0xa0 [ 292 5.143964] dwc3_gadget_free_endpoints+0x84/0xb0 [ 2925.148675] dwc3_gadget_exit+0x28/0x78 [ 2925.152518] dwc3_drd_exit +0x100/0x1f8 [ 2925.156267] dwc3_remove+0x11c/0x120 [ 2925.159851] dwc3_shutdown+0x14/0x20 [ 2925.163432] platform_shutdown+0x28/0x38 [ 2925.167360] apagado+0x15c/0x378 [ 2925.171291] kernel_restart_prepare+0x3c/0x48 [ 2925.175650] kernel_restart+0x1c /0x68 [ 2925.179316] __do_sys_reboot+0x218/0x240 [ 2925.183247] __arm64_sys_reboot+0x28/0x30 [ 2925.187262] invoke_syscall+0x48/0x100 [ 2925.191017 ] el0_svc_common.constprop.0+0x48/0xc8 [ 2925.195726] do_el0_svc+0x28/0x88 [ 2925.199045] el0_svc +0x20/0x30 [ 2925.202104] el0_sync_handler+0xa8/0xb0 [ 2925.205942] el0_sync+0x148/0x180 [ 2925.209270] Código: a9025bf5 2a0203f5 121f0056 370802b5 9400660) [ 2925.215372] ---[ rastreo final 124254d8e485a58b ]--- [ 2925.220012] Núcleo pánico - no se sincroniza: ¡Intenté matar init! ExitCode = 0x0000000b [2925.227676] Offset del núcleo: deshabilitado [2925.231164] Características de la CPU: 0x00001001,20000846 [2925.235521] Límite de memoria: Ninguno [2925.238580] --- [final de Kernel Panic -No Syncing: Intento de matar init! código de salida=0x0000000b ]--- (seleccionado del compromiso 2a042767814bd0edf2619f06fecd374e266ea068)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/slub: en realidad corrige el puntero de lista libre frente a redzoning. Resulta que SLUB redzoning ("slub_debug=Z") verifica desde s->object_size en lugar de s->inuse (que normalmente se elimina para dejar espacio para el puntero de lista libre), por lo que un caché creado con un tamaño de objeto menor a 24 tendría el puntero de lista libre escrito más allá de s->object_size, causando que el puntero de lista libre corrompa la zona roja. Esto fue muy visible con "slub_debug=ZF": prueba de BUG(contaminada: GB): zona roja derecha sobrescrita ---------------------------- ------------------------------------------------- INFORMACIÓN : 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. Primer byte 0x1a en lugar de 0xbb INFORMACIÓN: slab 0xffffef3950b47000 objetos=170 usados=170 fp=0x0000000000000000 banderas=0x80000000000000200 INFORMACIÓN: Objeto 0xffff957ead1c05d8 @offset=1496 fp=0xffff9 57ead1c0620 Zona roja (____ptrval____): bb bb bb bb bb bb bb bb .... .... Objeto (____ptrval____): 00 00 00 00 00 f6 f4 a5 ........ Redzone (____ptrval____): 40 1d e8 1a aa @.... Relleno (____ptrval____): 00 00 00 00 00 00 00 00 ........ Ajuste el desplazamiento para permanecer dentro de s->object_size. (Tenga en cuenta que actualmente no se sabe que existan cachés de este rango de tamaño en el kernel).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: corrige el refcnt dst del túnel vlan al salir El código del túnel de salida usa dst_clone() y establece directamente el resultado que es incorrecto porque la entrada puede tener 0 refcnt o ya estar eliminada , causando varios problemas. También activa WARN_ON() en dst_hold()[1] cuando no se puede tomar una referencia. Solucionelo usando dst_hold_safe() y verificando si realmente se tomó una referencia antes de configurar el dst. [1] Registro dmesg WARN_ON y siguientes errores de referencia ADVERTENCIA: CPU: 5 PID: 38 en include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [puente] Módulos vinculados en: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU : 5 PID: 38 Comm: ksoftirqd/5 Kdump: cargado Contaminado: GW 5.13.0-rc3+ #360 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 01/04/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [puente] Código: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 f6 e8 64 a.C. 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 00000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08: 0000000000000000 R09: 00000000000000001 R10: 2ce93d0054fe0d00 R11: d00000e0000 R12: ffff888109515000 R13: 0000000000000000 R14: 0000000000000001 R15: 00000000000000401 FS: 0000000000000000(0000) 8822bf40000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Seguimiento de llamadas: br_handle_vlan+0xbc/0xca [puente] _forward+0x23/0x164 [puente] delivery_clone+0x41/0x48 [puente] br_handle_frame_finish+0x36f/ 0x3aa [puente] ? skb_dst+0x2e/0x38 [puente]? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [puente]? br_handle_frame_finish+0x3aa/0x3aa [puente] br_handle_frame+0x2c3/0x377 [puente]? __skb_pull+0x33/0x51? vlan_do_receive+0x4f/0x36a? br_handle_frame_finish+0x3aa/0x3aa [puente] __netif_receive_skb_core+0x539/0x7c6? __list_del_entry_valid+0x16e/0x1c2 __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140 napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9 net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirq d+0x18/0x20 smpboot_thread_fn+0x183/0x19c ? smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f? kthread_mod_delayed_work+0xb6/0xb6 ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1 dst_release underflow

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: corrige la desreferencia del puntero null del túnel vlan dst Este parche corrige una desreferencia del puntero null de Tunnel_dst debido al acceso sin bloqueo en la ruta de salida del túnel. Al eliminar un túnel VLAN, el puntero Tunnel_dst se establece en NULL sin esperar un período de gracia (es decir, mientras aún se puede utilizar) y los paquetes que salen lo desreferencian sin verificarlo. Use READ/WRITE_ONCE para anotar el uso sin bloqueo de Tunnel_id, use RCU para acceder a Tunnel_dst y asegúrese de que se lea solo una vez y se verifique en la ruta de salida. El dst ya está correctamente protegido por la RCU, por lo que no necesitamos hacer nada sofisticado más que asegurarnos de que Tunnel_id y Tunnel_dst se lean solo una vez y se verifiquen en la ruta de salida.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:ll_temac: Asegúrate de liberar skb cuando esté completamente utilizado. Con el puntero skb acoplado en la BD TX, tenemos una forma sencilla y eficaz de liberar el buffer skb. cuando la trama ha sido transmitida. Pero para evitar liberar el skb mientras todavía hay fragmentos del skb en uso, debemos aprovechar el BD TX del skb, no el primero. Sin esto, estamos haciendo use after free en el lado DMA, cuando el primer BD de un paquete BD de transmisión múltiple se considera completado en xmit_done y los BD restantes todavía se están procesando.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: corrige el punto muerto en el manejo de AP/VLAN. Syzbot informa que cuando tienes interfaces AP_VLAN activas y cierras la interfaz AP a la que pertenecen, obtenemos un punto muerto. No es de extrañar, ya que los dev_close() los usamos con el mutex wiphy retenido, lo que regresa al notificador netdev en cfg80211 e intenta adquirir el mutex wiphy allí. Para solucionar esto, debemos hacer dos cosas: 1) evitar cambiar iftype mientras las AP_VLAN estén activas, no podemos solucionar fácilmente este caso ya que cfg80211 ya nos llama con el mutex wiphy retenido, pero change_interface() es relativamente raro en los controladores de todos modos , por lo que cambiar iftype no se usa mucho (y el espacio de usuario tiene que volver a bajar/cambiar/arriba de todos modos) 2) extraiga el bucle dev_close() sobre las VLAN de la sección wiphy mutex en el caso de detención normal

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Invalida el estado de la FPU después de un XRSTOR fallido desde un búfer de usuario. Tanto Intel como AMD consideran que es arquitectónicamente válido que XRSTOR falle con #PF pero aun así cambie el estado del registro. . Las condiciones reales bajo las cuales esto podría ocurrir no están claras [1], pero parece plausible que esto pueda desencadenarse si un hilo hermano desasigna una página e invalida el TLB compartido mientras otro hilo hermano está ejecutando XRSTOR en la página en cuestión. __fpu__restore_sig() puede ejecutar XRSTOR mientras los registros de hardware se conservan en nombre de una tarea de víctima diferente (usando el mecanismo fpu_fpregs_owner_ctx) y, en teoría, XRSTOR podría fallar pero modificar los registros. Si esto sucede, entonces hay una ventana en la que __fpu__restore_sig() podría programar la salida y la tarea de la víctima podría volver a programarse sin recargar sus propios registros FPU. Esto resultaría en parte del estado de la FPU en el que __fpu__restore_sig() intentaba cargar una filtración en el estado visible para el usuario de la tarea de la víctima. Invalide los registros FPU preservados en caso de falla de XRSTOR para evitar que esta situación corrompa cualquier estado. [1] Los lectores frecuentes de las listas de erratas podrían imaginar "condiciones microarquitectónicas complejas".

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/fpu: evita la corrupción del estado en __fpu__restore_sig() La ruta lenta no compactada usa __copy_from_user() y copia todo el búfer del usuario en el búfer del kernel, palabra por palabra. Esto significa que el búfer del kernel ahora puede contener un estado completamente inválido en el que XRSTOR realizará #GP. validar_user_xstate_header() puede detectar parte de esa corrupción, pero eso deja a las personas que llaman la responsabilidad de borrar el búfer. Antes de la compatibilidad con XSAVES, era posible simplemente reinicializar el búfer por completo, pero con los estados del supervisor eso ya no es posible porque la división del código de borrado del búfer lo hacía al revés. Arreglar eso es posible, pero no corromper al Estado en primer lugar es más sólido. Evite la corrupción del búfer XSAVE del kernel utilizando copy_user_to_xstate() que valida el contenido del encabezado XSAVE antes de copiar los estados reales al kernel. copy_user_to_xstate() anteriormente solo se llamaba para buffers del kernel en formato compacto, pero funciona tanto para formatos compactos como no compactos. Usarlo para el formato no compacto es más lento debido a múltiples operaciones __copy_from_user(), pero ese costo es menos importante que el código robusto en una ruta que ya es lenta. [Registro de cambios pulido por Dave Hansen]