Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/secretmem: corrige la página NULL->desreferencia de mapeo en page_is_secretmem() Verifique si hay una página NULL->mapping antes de desreferenciar el mapeo en page_is_secretmem(), ya que el mapeo de la página puede ser anulado mientras se ejecuta gup(), por ejemplo, mediante recuperación o truncamiento. ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000068 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - página no presente PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 4173897 Comunicaciones: CPU 3/KVM contaminada: GW RIP: 0010:internal_get_user_pages_fast+0x621/0x9d0 Código: <48> 81 7a 68 80 08 04 bc 0f 85 21 ff ff 8 89 c7 be RSP: ffffaa90087679 b0 EFLAGS: 00010046 RAX: ffffe3f37905b900 RBX: 00007f2dd561e000 RCX: ffffe3f37905b934 RDX: 0000000000000000 RSI: 00000000000000000 RDI: ffffe3f37905b900 ... CR2: 0000068 CR3: 00000004c5898003 CR4: 00000000001726e0 Seguimiento de llamadas: get_user_pages_fast_only+0x13/0x20 hva_to_pfn+0xa9/0x3e0 try_async_pf+0xa1/0x270 direct_page_fault+0x113/ 0xad0 kvm_mmu_page_fault+0x69/0x680 vmx_handle_exit+0xe1/0x5d0 kvm_arch_vcpu_ioctl_run+0xd81/0x1c70 kvm_vcpu_ioctl+0x267/0x670 __x64_sys_ioctl+0x83/0xa0 scall_64+0x56/0x80 entrada_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: auditoría: corrige una posible desreferencia de puntero nulo en audit_filter_rules. Corrige una posible desreferencia de puntero nulo en audit_filter_rules. Error audit_filter_rules(): previamente asumimos que 'ctx' podría ser nulo

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().