Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: userfaultfd: corrige una ejecución entre writeprotect y exit_mmap() Una ejecución es posible cuando un proceso sale, sus VMA son eliminados por exit_mmap() y al mismo tiempo se llama a userfaultfd_writeprotect() . KASAN detectó la ejecución en un núcleo de desarrollo, pero parece ser posible también en núcleos de vainilla. Utilice mmget_not_zero() para evitar la ejecución como se hace en otras operaciones de userfaultfd.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: mm/mempolicy: no permitir MPOL_F_NUMA_BALANCING ilegal | MPOL_LOCAL en mbind() syzbot informó acceso a la memoria unificada en mbind() [1] El problema surgió con el commit bda420b98505 ("equilibrio numa: migrar en caso de falla entre múltiples nodos vinculados") Esta confirmación agregó un nuevo bit en MPOL_MODE_FLAGS, pero solo marcó que era válido combinación (MPOL_F_NUMA_BALANCING solo se puede usar con MPOL_BIND) en do_set_mempolicy() Este parche mueve la verificación en sanitize_mpol_flags() para que también sea usado por mbind() [1] ERROR: KMSAN: valor uninit en __mpol_equal+0x567/0x590 mm /mempolicy.c:2260 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h:105 [en línea] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/ mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [en línea] __do_sys_mbind mm/mempolicy.c:1490 [en línea] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c: 1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0 Unidad x44/0xae fue creado en: slab_alloc_node mm/slub.c:3221 [en línea] slab_alloc mm/slub.c:3230 [en línea] kmem_cache_alloc+0x751/0xff0 mm/slub.c:3235 mpol_new mm/mempolicy.c:293 [en línea] do_mbind +0x912/0x15f0 mm/mempolicy.c:1289 kernel_mbind mm/mempolicy.c:1483 [en línea] __do_sys_mbind mm/mempolicy.c:1490 [en línea] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0 x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae ======= =============================================== Pánico del kernel - no sincronización: pánico_on_kmsan set... CPU: 0 PID: 15049 Comm: syz-executor.0 Contaminado: GB 5.15.0-rc2-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/ Seguimiento de llamadas de 2011: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x1ff/0x28e lib/dump_stack.c:106 dump_stack+0x25/0x28 lib/dump_stack.c:113 pánico+0x44f/0xdeb kernel/panic.c: 232 kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186 __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h: 105 [en línea] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [en línea ] __do_sys_mbind mm/mempolicy.c:1490 [en línea] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common. c:51 [en línea ] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 Entry_SYSCALL_64_after_hwframe+0x44/0xae

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---