Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: restablece inmediatamente el contexto de MMU cuando se borra el indicador SMM Restablece inmediatamente el contexto de MMU cuando se borra el indicador SMM de la vCPU para que el indicador SMM en la función MMU esté siempre sincronizado con el indicador de la vCPU. Si RSM falla (que no se emula correctamente), KVM se retirará sin llamar a post_leave_smm() y dejará la MMU en mal estado. La función incorrecta de MMU puede provocar una desreferencia del puntero NULL al tomar el rmap de una página oculta para una falla de página, ya que las búsquedas iniciales para gfn se realizarán con el indicador SMM de la vCPU (=0), mientras que la búsqueda de rmap utilizará el SMM de la página oculta. bandera, que proviene de la MMU (=1). SMM tiene un conjunto de ranuras de memoria completamente diferente, por lo que la búsqueda inicial puede encontrar una ranura de memoria (SMM=0) y luego explotar en la búsqueda de ranura de memoria de rmap (SMM=1). falla de protección general, probablemente para dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en rango [0x0000000000000000-0x00000000000000007] CPU: 1 PID: 8410 Comm: No contaminado 5.13.0 -rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [en línea] RIP: 0010: gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947 Código: <42> 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44 RSP:ffffc90000ffe f98 EFLAGS : 00010246 RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40 RDX: 00000000000000000 RSI: 0000000000000001 RDI: 00000000000 00001 RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002 R10: ffffed10065a6002 R11: 00000000000000000 R12: dffffc0000000000 R13: 0000000000003 R14: 0000000000000001 R15: 0000000000000000 FS: 000000000124b300 (0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 8e31000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: rmap_add arch/x86/kvm/mmu/mmu.c:965 [en línea] mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604 __direct_map arch/x86/kvm/mmu/mmu. c:2862 [en línea] direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769 kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [en línea] kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/ mmu/mmu.c:5065 vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122 vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428 vcpu_run+0x416/0xc20 arch/x86/ kvm/x86.c:9494 kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722 kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c :3460 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:1069 [en línea] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c :47 entrada_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x440ce9

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: can: mcba_usb: repara la pérdida de memoria en mcba_usb. Syzbot informó una pérdida de memoria en el controlador SocketCAN para la herramienta Microchip CAN BUS Analyzer. El problema estaba en usb_coherent no liberado. En mcba_usb_start() se asignan 20 buffers coherentes y no hay nada que los libere: 1) En la función de devolución de llamada, la urb se vuelve a enviar y eso es todo 2) En la función de desconexión, las urbs simplemente se eliminan, pero URB_FREE_BUFFER no está configurado (ver mcba_usb_start) y Esta bandera no se puede utilizar con buffers coherentes. Registro de errores: | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: dispositivo desconectado | [ 1367.059384][ T8420] kmemleak: 20 nuevas pérdidas de memoria sospechosas (ver /sys/kernel/debug/kmem) Por lo tanto, todos los buffers asignados deben liberarse con usb_free_coherent() explícitamente NOTA: Se utiliza el mismo patrón para asignar y liberar buffers coherentes en controladores/net/can/usb/kvaser_usb/kvaser_usb_core.c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: corrige Use-after-Free, mantenga presionada la referencia skb mientras está en uso. Este parche corrige un Use-after-Free encontrado por syzbot. El problema es que se toma un skb de la cola de skb por sesión, sin incrementar el recuento de referencias. Esto conduce a un use after free si el skb se toma simultáneamente de la cola de sesión debido a un CTS.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: regulador: rt4801: corrige la desreferencia del puntero NULL si priv->enable_gpios es NULL, devm_gpiod_get_array_optional puede devolver NULL si no se asignó ningún GPIO.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phy: phy-mtk-tphy: solucione algunas fugas de recursos en mtk_phy_init() Utilice clk_disable_unprepare() en la ruta de error de mtk_phy_init() para solucionar algunas fugas de recursos.

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