Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: PPC: Book3S HV: Arreglar el manejo de la pila en idle_kvm_start_guest() En el commit 10d91611f426 ("powerpc/64s: Reimplementar el código inactivo de book3s en C") kvm_start_guest() se convirtió en idle_kvm_start_guest() . El código antiguo asignaba un marco de pila en la pila de emergencia, pero no usaba el marco para almacenar nada y tampoco almacenaba nada en el marco de la persona que llama. idle_kvm_start_guest(), por otro lado, se escribe más como una función C normal, crea un marco al ingresar y también almacena CR/LR en el marco de la persona que llama (según la ABI). El problema es que no hay ningún marco de llamada en la pila de emergencia. La pila de emergencia para una CPU determinada se asigna con: paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE; Entonces, Emergency_sp en realidad apunta a la primera dirección encima de la asignación de pila de emergencia para una CPU determinada; no debemos almacenar encima de ella sin primero disminuirla para crear un marco. Esto es diferente a la pila normal del kernel, paca->kstack, que se inicializa para apuntar a un marco inicial que está listo para usar. idle_kvm_start_guest() almacena la cadena posterior, CR y LR, todos los cuales escriben fuera de la asignación para la pila de emergencia. Luego crea un marco de pila y guarda los registros no volátiles. Desafortunadamente, el marco que crea no es lo suficientemente grande para acomodar los registros no volátiles, por lo que guardar los registros no volátiles también escribe fuera de la asignación de pila de emergencia. El resultado final es que corrompemos todo lo que esté entre 0 y 24 bytes y entre 112 y 248 bytes por encima de la asignación de pila de emergencia. En la práctica, esto ha pasado desapercibido porque la memoria inmediatamente encima de la pila de emergencia se usa para otras asignaciones de pila, ya sea otra CPU mc_emergency_sp o una pila IRQ. Vea el orden de las llamadas a irqstack_early_init() y Emergency_stack_init(). Las direcciones bajas de otra pila están en la parte superior de esa pila, por lo que solo se usan si esa pila está bajo una presión extrema, lo que esencialmente nunca sucede en la práctica, y si así fuera, existe una alta probabilidad de que fallemos debido a que esa pila se desborde. . Aún así, no deberíamos estar corrompiendo la pila de otra persona, y es pura suerte que no estemos corrompiendo algo más. Para solucionarlo, guardamos CR/LR en el marco de la persona que llama usando el r1 existente en la entrada, luego creamos un marco SWITCH_FRAME_SIZE (que tiene espacio para pt_regs) en la pila de emergencia con la cadena posterior apuntando a la pila existente, y finalmente cambiamos al nuevo marco en la pila de emergencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, slub: corrige una posible pérdida de memoria en kmem_cache_open() En la ruta del error, es posible que se haya filtrado el random_seq del caché slub. Solucione este problema usando __kmem_cache_release() para liberar todos los recursos relevantes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kunit: corrige la fuga del recuento de referencias en kfree_at_end El problema del recuento de referencias ocurre en la ruta normal de kfree_at_end(). Cuando se invoca kunit_alloc_and_get_resource(), la función se olvida de manejar el objeto de recurso devuelto, cuyo recuento aumentó en el interior, lo que provoca una fuga de recuento. Solucione este problema llamando a kunit_alloc_resource() en lugar de kunit_alloc_and_get_resource(). Se corrigió lo siguiente al aplicar: Shuah Khan VERIFICAR: La alineación debe coincidir con el paréntesis abierto + kunit_alloc_resource(test, NULL, kfree_res_free, GFP_KERNEL, (void *)to_free);

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: isdn: mISDN: corrige la función de suspensión llamada desde un contexto no válido. El controlador puede llamar a la función card->isac.release() desde un contexto atómico. Solucione este problema llamando a esta función después de liberar el bloqueo. El siguiente registro lo revela: [44.168226] ERROR: función inactiva llamada desde un contexto no válido en kernel/workqueue.c:3018 [44.168941] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, nombre: modprobe [44.169574] INFORMACIÓN: lockdep está desactivado. [ 44.169899 ] sello de evento irq: 0 [ 44.170160 ] hardirqs habilitado por última vez en (0): [<0000000000000000>] 0x0 [ 44.170627 ] hardirqs deshabilitado por última vez en (0): [] copy_process+0x132d/0x3e00 [ 44.171240 ] softirqs habilitado por última vez en (0): [] copy_process+0x135a/0x3e00 [ 44.171852 ] softirqs deshabilitado por última vez en (0): [<00000000000000000>] 0x0 [ 44.172318 ] Preferencia deshabilitada en: [ 44.172320 ] ffa009b0a9>] nj_release +0x69/0x500 [netjet] [ 44.174441 ] Seguimiento de llamadas: [ 44.174630 ] dump_stack_lvl+0xa8/0xd1 [ 44.174912 ] dump_stack+0x15/0x17 [ 44.175166 ] ___might_sleep+0x3a2/0x510 [ 44.175459 ] ? nj_release+0x69/0x500 [netjet] [ 44.175791 ] __might_sleep+0x82/0xe0 [ 44.176063 ] ? start_flush_work+0x20/0x7b0 [ 44.176375 ] start_flush_work+0x33/0x7b0 [ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170 [44.177034]? kasan_quarantine_put+0xaa/0x1f0 [ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177711 ] __flush_work+0x11a/0x1a0 [ 44.177991 ] ? Flush_work+0x20/0x20 [44.178257]? lock_release+0x13c/0x8f0 [44.178550]? __kasan_check_write+0x14/0x20 [44.178872]? do_raw_spin_lock+0x148/0x360 [44.179187]? read_lock_is_recursive+0x20/0x20 [44.179530]? __kasan_check_read+0x11/0x20 [44.179846]? do_raw_spin_unlock+0x55/0x900 [44.180168]? ____kasan_slab_free+0x116/0x140 [44.180505]? _raw_spin_unlock_irqrestore+0x41/0x60 [44.180878]? skb_queue_purge+0x1a3/0x1c0 [44.181189]? kfree+0x13e/0x290 [ 44.181438 ] Flush_work+0x17/0x20 [ 44.181695 ] mISDN_freedchannel+0xe8/0x100 [ 44.182006 ] isac_release+0x210/0x260 [mISDNipac] [ 44.182366 nj _release+0xf6/0x500 [netjet] [ 44.182685 ] nj_remove+0x48/ 0x70 [netjet] [44.182989] pci_device_remove+0xa9/0x250

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: soluciona el punto muerto al agregar controladores SPI en buses SPI. Actualmente tenemos un spi_add_lock global que utilizamos cuando agregamos nuevos dispositivos para que podamos verificar que no estamos intentando reutilizar un selección de chip que ya está controlado. Esto significa que si el dispositivo SPI es en sí mismo un controlador SPI y activa la creación de instancias de otros dispositivos SPI, desencadenaremos un punto muerto cuando intentamos registrar y crear instancias de esos dispositivos mientras estamos en el proceso de hacerlo para el controlador principal y, por lo tanto, ya tenemos el control global. spi_add_lock. Dado que solo nos importa la concurrencia dentro de un único bus SPI, mueva el bloqueo para que sea por controlador, evitando el punto muerto. Esto se puede activar fácilmente en el caso de spi-mux.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm, slub: corrige el posible use-after-free en slab_debugfs_fops Cuando sysfs_slab_add falla, no debemos llamar a debugfs_slab_add() para s porque s se liberará pronto. Y slab_debugfs_fops usará s más tarde, lo que conducirá a un use-after-free.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm: mxsfb: corrige el fallo de desreferencia del puntero NULL al descargar Es posible que mxsfb->crtc.funcs ya sea NULL al descargar el controlador, en cuyo caso se llama a mxsfb_irq_disable() a través de drm_irq_uninstall() desde mxsfb_unload() conduce a la desreferencia del puntero NULL. Dado que lo único que nos importa es enmascarar la IRQ y mxsfb->base sigue siendo válido, simplemente utilícelo para borrar y enmascarar la IRQ.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: mdiobus: corrige la pérdida de memoria en __mdiobus_register Una vez que falló device_register(), debemos llamar a put_device() para disminuir el recuento de referencias para la sanitización. O provocará una pérdida de memoria. Error: fuga de memoria objeto no referenciado 0xffff888114032e00 (tamaño 256): Comm "KWorker/1: 3", PID 2960, Jiffies 4294943572 (Edad 15.920) Volcado Hex (Primer 32 bytes): 00 00 00 00 00 00 00 08 2E 03333 14 81 88 y ff ................ 08 2e 03 14 81 88 y ff 90 76 65 82 y ff ff ff .........ve... .. backtrace: [] kmalloc include/linux/slab.h:591 [en línea] [] kzalloc include/linux/slab.h:721 [en línea] [] device_private_init drivers/base/ core.c:3203 [en línea] [] device_add+0x89b/0xdf0 drivers/base/core.c:3253 [] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537 [< ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87 [] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [en línea] [] 88772_bind+controladores 0x330/0x480 /net/usb/asix_devices.c:786 [] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c :396 [] call_driver_probe controladores/base/dd.c:517 [en línea] [] reality_probe.part.0+0xe7/0x380 controladores/base/dd.c:596 [] controladores very_probe /base/dd.c:558 [en línea] [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751 [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781 [ ] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898 [] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427 [] __device_attach+0x122/0 controladores x260/base /dd.c:969 [] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487 [] device_add+0x5fb/0xdf0 drivers/base/core.c:3359 [] usb_set_configuration +0x9d9/0xb90 drivers/usb/core/message.c:2170 [] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 ERROR: pérdida de memoria objeto sin referencia 0xffff888116f06900 (tamaño 32): comm " kworker/0:2", pid 2670, jiffies 4294944448 (edad 7,160 s) volcado hexadecimal (primeros 32 bytes): 75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00 usb-001:003.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ rastreo inverso: [] kstrdup+0x36/0x70 mm/util.c :60 [] kstrdup_const+0x53/0x80 mm/util.c:83 [] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48 [] kobject_set_name_vargs+0x3b/0 xe0 lib/kobject. c:289 [] dev_set_name+0x63/0x90 drivers/base/core.c:3147 [] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535 [] __devm_mdiobus_ registrarse+ 0x75/0xf0 controladores/net/phy/mdio_devres.c:87 [] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [en línea] [] ax88772_bind+0x330/0x480 controladores/net/usb / asix_devices.c:786 [] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [] call_driver_probe drivers/base/dd.c:517 [en línea] []realmente_probe.part.0+0xe7/0x380 drivers/base/dd.c:596 []realmente_probe drivers/base/dd. c:558 [en línea] [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751 [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781 [] tacómetro +0xf6/0x140 drivers/base/dd.c:898 [] bus_for_each ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: corrige el bloqueo para el vaciado del seguimiento de la marca de tiempo de Tx. Commit 4dd0d5c33c3e ("ice: agrega bloqueo alrededor del vaciado del rastreador de marca de tiempo de Tx") agregó un bloqueo alrededor del flujo del rastreador de marca de tiempo de Tx que se utiliza para la sanitización. cualquier SKB sobrante y prepárese para retirar el dispositivo. Este bloqueo es problemático porque se mantiene en torno a una llamada a ice_clear_phy_tstamp. La función de borrado requiere un mutex para enviar un comando de escritura PHY al firmware. Esto podría llevar a un punto muerto si el mutex realmente duerme y causa la siguiente advertencia en un kernel con la depuración de prioridad habilitada: [715.419426] ERROR: función de dormir llamada desde un contexto no válido en kernel/locking/mutex.c:573 [715.427900] in_atomic (): 1, irqs_disabled(): 0, non_block: 0, pid: 3100, nombre: rmmod [715.435652] INFORMACIÓN: lockdep está desactivado. [715.439591] Prelación deshabilitada en: [715.439594] [<0000000000000000>] 0x0 [715.446678] CPU: 52 PID: 3100 Comm: rmmod Contaminado: GW OE 5.15.0-rc4+ #42 bdd7ec3018e725f 159ca0d372ce8c2c0e784891c [ 715.458058] Nombre del hardware: Intel Corporation S2600STQ/ S2600STQ, BIOS SE5C620.86B.02.01.0010.010620200716 06/01/2020 [715.468483] Seguimiento de llamadas: [715.470940] dump_stack_lvl+0x6a/0x9a [715.474613] ___might_sleep. frío+0x224/0x26a [ 715.478895] __mutex_lock+0xb3/0x1440 [ 715.482569] ? stack_depot_save+0x378/0x500 [715.486763]? ice_sq_send_cmd+0x78/0x14c0 [hielo 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.494979]? kfree+0xc1/0x520 [ 715.498128] ? mutex_lock_io_nested+0x12a0/0x12a0 [715.502837]? kasan_set_free_info+0x20/0x30 [715.507110]? __kasan_slab_free+0x10b/0x140 [715.511385] ? slab_free_freelist_hook+0xc7/0x220 [715.516092]? kfree+0xc1/0x520 [ 715.519235] ? ice_deinit_lag+0x16c/0x220 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.527359]? ice_remove+0x1cf/0x6a0 [hielo 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.535133]? pci_device_remove+0xab/0x1d0 [715.539318]? __device_release_driver+0x35b/0x690 [715.544110] ? driver_detach+0x214/0x2f0 [715.548035]? bus_remove_driver+0x11d/0x2f0 [715.552309]? pci_unregister_driver+0x26/0x250 [715.556840]? ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.564799]? __do_sys_delete_module.constprop.0+0x2d8/0x4e0 [715.570554]? do_syscall_64+0x3b/0x90 [715.574303]? entrada_SYSCALL_64_after_hwframe+0x44/0xae [715.579529]? start_flush_work+0x542/0x8f0 [715.583719]? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.591923] ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc 7da2b3786a421d] [715.599960]? wait_for_completion_io+0x250/0x250 [715.604662]? lock_acquire+0x196/0x200 [715.608504]? do_raw_spin_trylock+0xa5/0x160 [715.612864] ice_sbq_rw_reg+0x1e6/0x2f0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.620813]? ice_reset+0x130/0x130 [hielo 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.628497]? __debug_check_no_obj_freed+0x1e8/0x3c0 [715.633550]? trace_hardirqs_on+0x1c/0x130 [715.637748] ice_write_phy_reg_e810+0x70/0xf0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.646220]? do_raw_spin_trylock+0xa5/0x160 [715.650581]? ice_ptp_release+0x910/0x910 [hielo 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.658797]? ice_ptp_release+0x255/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.667013] ice_clear_phy_tstamp+0x2c/0x110 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3 786a421d] [715.675403] ice_ptp_release+0x408/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [715.683440] ice_remove+0x560/0x6a0 [ice 9a7e1ec00971 c89ecd3fe0d4dc7da2b3786a421d] [715.691037]? _raw_spin_unlock_irqrestore+0x46/0x73 [ 715.696005] pci_device_remove+0xab/0x1d0 [ 715.700018] __device_release_driver+0x35b/0x690 [ 715.704637] driver_detach+0x214/0x2f0 [ 715 .708389] bus_remove_driver+0x11d/0x2f0 [ 715.712489] pci_unregister_driver+0x26/0x250 [ 71 --- truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: corrige el recuento de PGD de etapa 2 del host La librería de tablas de páginas de KVM vuelve a contar las páginas de los PGD de etapa 2 concatenados individualmente. Sin embargo, cuando se ejecuta KVM en modo protegido, EL2 administra actualmente el PGD de etapa 2 del host como una única página compuesta de alto orden, lo que puede causar que el recuento de las páginas finales llegue a 0 cuando no debería, corrompiendo así el tabla de páginas. Solucione este problema introduciendo un nuevo asistente hyp_split_page() en el asignador de páginas EL2 (que coincida con la función split_page() del kernel) y utilícelo desde host_s2_zalloc_pages_exact().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: xt_IDLETIMER: corrige el pánico que ocurre cuando timer_type tiene valor basura Actualmente, cuando se agrega la regla relacionada con IDLETIMER, kmalloc inicializa la estructura del temporizador idletimer_tg al ejecutar la función idletimer_tg_create. Sin embargo, en este proceso timer->timer_type no está definido en un valor específico. Por lo tanto, timer->timer_type tiene un valor basura y se produce un pánico en el kernel. Entonces, esta confirmación soluciona el pánico al inicializar timer->timer_type usando kzalloc en lugar de kmalloc. Comandos de prueba: # iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test $ cat /sys/class/xt_idletimer/timers/test Killed Splat se ve así: ERROR: KASAN: acceso a memoria de usuario en alarm_expires_remaining+0x49/ 0x70 Lectura del tamaño 8 en la dirección 0000002e8c7bc4c8 por tarea cat/917 CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 009), BIOS 1.13.0- 1ubuntu1.1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x6e/0x9c kasan_report.cold+0x112/0x117 ? alarm_expires_remaining+0x49/0x70 __asan_load8+0x86/0xb0 alarm_expires_remaining+0x49/0x70 idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d] tr_show+0x3c/0x60 sysfs_kf_seq_show+0x11d/0x1f0 ? device_remove_bin_file+0x20/0x20 kernfs_seq_show+0xa4/0xb0 seq_read_iter+0x29c/0x750 kernfs_fop_read_iter+0x25a/0x2c0 ? __fsnotify_parent+0x3d1/0x570? iov_iter_init+0x70/0x90 new_sync_read+0x2a7/0x3d0? __x64_sys_llseek+0x230/0x230 ? rw_verify_area+0x81/0x150 vfs_read+0x17b/0x240 ksys_read+0xd9/0x180 ? vfs_write+0x460/0x460? do_syscall_64+0x16/0xc0? lockdep_hardirqs_on+0x79/0x120 __x64_sys_read+0x43/0x50 do_syscall_64+0x3b/0xc0 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f0cdc819142 Código: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 RSP: :00007fff28eee5b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 000000000020000 RCX: 00007f0cdc819142 RDX: 0000000000020000 RSI: 00007f0cdc03200 0 RDI: 0000000000000003 RBP: 00007f0cdc032000 R08: 00007f0cdc031010 R09: 0000000000000000 R10: 0000000000000022 R11: 00000000000000246 R 12: 00005607e9ee31f0 R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: omitir eventos de netdev generados al eliminar netns syzbot informó lo siguiente (inofensivo) ADVERTENCIA: ADVERTENCIA: CPU: 1 PID: 2648 en net/netfilter/core.c:468 nft_netdev_unregister_hooks net/netfilter/nf_tables_api.c:230 [en línea] nf_tables_unregister_hook include/net/netfilter/nf_tables.h:1090 [en línea] __nft_release_basechain+0x138/0x640 net/netfilter/nf_tables_api.c:9524 nft_netdev_event net/netfilter/nft_ filtro_cadena.c: 351 [en línea] nf_tables_netdev_event+0x521/0x8a0 net/netfilter/nft_chain_filter.c:382 reproductor: dejar de compartir -n bash -c 'ip link agregar puente tipo br0; nft agregar tabla netdev t; \ nft add chain netdev t ingress \{ tipo filtro gancho ingreso dispositivo "br0" \ prioridad 0\; caída de la política\; \}' El problema es que cuando los ganchos de salida del dispositivo netns crean el evento UNREGISTER, el gancho .pre_exit para nf_tables core ya ha eliminado el gancho base. Notifier intenta hacer esto nuevamente. La necesidad de cancelar el registro del enlace base incondicionalmente era necesaria en el pasado, porque el notificador era la última etapa donde la desreferencia reg->dev era segura. Ahora que nf_tables elimina el gancho en .pre_exit, esto ya no es necesario.