Vulnerabilidades

IBM CICS TX Advanced 10.1 es vulnerable a Cross-Site Scripting. Esta vulnerabilidad permite a los usuarios incrustar código JavaScript arbitrario en la interfaz de usuario web, alterando así la funcionalidad prevista, lo que podría conducir a la divulgación de credenciales dentro de una sesión confiable. ID de IBM X-Force: 260769.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tun: evita la doble liberación en tun_free_netdev Evita la doble liberación en tun_free_netdev() moviendo las asignaciones dev->tstats y tun->security a una nueva rutina ndo_init (tun_net_init()) que será llamado por Register_netdevice(). ndo_init está emparejado con el destructor (tun_free_netdev()), por lo que si hay un error en Register_netdevice() el destructor manejará las liberaciones. ERROR: KASAN: doble liberación o no válido en selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605 CPU: 0 PID: 25750 Comm: syz-executor416 No contaminado 5.16.0-rc2-syzk #1 Nombre de hardware : Red Hat KVM, seguimiento de llamadas de BIOS: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report. c:247 kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372 ____kasan_slab_free mm/kasan/common.c:346 [en línea] __kasan_slab_free+0x107/0x120 mm/kasan/common.c:374 kasan_slab_free include/linux/kasan .h:235 [en línea] slab_free_hook mm/slub.c:1723 [en línea] slab_free_freelist_hook mm/slub.c:1749 [en línea] slab_free mm/slub.c:3513 [en línea] kfree+0xac/0x2d0 mm/slub.c :4561 selinux_tun_dev_free_security+0x1a/0x20 seguridad/selinux/hooks.c:5605 seguridad_tun_dev_free_security+0x4f/0x90 seguridad/seguridad.c:2342 tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215 netdev_run_todo+0x4df/0x840 net/ núcleo /dev.c:10627 rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112 __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302 tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311 vfs_ioctl fs /ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:874 [en línea] __se_sys_ioctl fs/ioctl.c:860 [en línea] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/ common.c:50 [en línea] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pinctrl: mediatek: soluciona el problema global fuera de los límites Cuando el número eint virtual eint es mayor que el número gpio, puede producir un tamaño 'desc[eint_n]' globle-out- cuestión de fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hamradio: diferir ax25 kfree después de unregister_netdev Existe una posible condición de ejecución (use-after-free) como la siguiente (USE) | (GRATIS) ax25_sendmsg | ax25_queue_xmit | dev_queue_xmit | __dev_queue_xmit | __dev_xmit_skb | sch_direct_xmit | ... xmit_one | netdev_start_xmit | tty_ldisc_kill __netdev_start_xmit | mkiss_close ax_xmit | kfree ax_encaps | | Aunque hay dos primitivas de sincronización antes de kfree: 1. wait_for_completion(&ax->dead). Esto puede evitar la ejecución con rutinas de mkiss_ioctl. Sin embargo, no puede detener la rutina que proviene de la capa superior, es decir, ax25_sendmsg. 2. netif_stop_queue(ax->dev). Parece que esta línea de código tiene como objetivo detener la cola de transmisión pero no logra detener la rutina que ya se está transmitiendo. Este parche reordena kfree después de unregister_netdev para evitar el posible UAF ya que unregister_netdev() está bien sincronizado y no regresará si hay una rutina en ejecución.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: hamradio: mejora la solución incompleta para evitar NPD. El commit anterior 3e0588c291d6 ("hamradio: defer ax25 kfree after unregister_netdev") reordena las operaciones kfree y unregister_netdev para prevenir UAF. Esta confirmación mejora la anterior al diferir también la anulación del puntero ax->tty. De lo contrario, se produce un error de desreferencia del puntero NULL. A continuación se muestra parte del seguimiento de la pila. ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000538 RIP: 0010:ax_xmit+0x1f9/0x400... Seguimiento de llamadas: dev_hard_start_xmit+0xec/0x320 sch_direct_xmit+0xea/0x240 __qdisc_run+0x166/0x5c0 __dev_queue_x mit+0x2c7/0xaf0 ax25_std_establecer_data_link+0x59/0x60 ax25_connect+0x3a0/0x500? seguridad_socket_connect+0x2b/0x40 __sys_connect+0x96/0xc0 ? __hrtimer_init+0xc0/0xc0? common_nsleep+0x2e/0x50? switch_fpu_return+0x139/0x1a0 __x64_sys_connect+0x11/0x20 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 El punto de bloqueo se muestra a continuación static void ax_encaps(...) { ... set_bit(TTY_DO_WRITE_WAKEUP, &ax-> tty->banderas ); // hacha->tty = NULL! ... } Al colocar la acción de anulación después de unregister_netdev, el puntero ax->tty no se asignará ya que la capa de marco NULL net_device está bien sincronizada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phonet/pep: se niega a habilitar una tubería independiente. Este ioctl() supone implícitamente que el socket ya estaba vinculado a un nombre de socket local válido, es decir, objeto Phonet. Si el socket no estuviera vinculado, se producirían dos problemas distintos: 1) Enviamos una solicitud de habilitación de canalización con un objeto fuente no válido. 2) Las llamadas de socket posteriores podrían ERROR en el socket que se conecta inesperadamente pero no está vinculado a un objeto válido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tee: optee: corrige el error de liberación de página incorrecta. El puntero a las páginas asignadas (página de estructura *página) ya ha avanzado hacia el final de la asignación. Es incorrecto ejecutar __free_pages(page, order) usando este puntero ya que liberaríamos páginas arbitrarias. Solucione este problema dejando de modificar el puntero de la página.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/dbgfs: protege las destrucciones de objetivos con kdamond_lock La interfaz DAMON debugfs itera los objetivos de monitoreo actuales en 'dbgfs_target_ids_read()' mientras mantiene el correspondiente 'kdamond_lock'. Sin embargo, también destruye los objetivos de monitoreo en 'dbgfs_before_terminate()' sin mantener el bloqueo. Esto puede provocar un error use_after_free. Este compromiso evita la ejecución protegiendo la destrucción con el correspondiente 'kdamond_lock'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kfence: repara la pérdida de memoria cuando los objetos cat kfence Hulk robot informó un problema kmemleak: objeto sin referencia 0xffff93d1d8cc02e8 (tamaño 248): comm "cat", pid 23327, jiffies 4624670141 (edad 495992.217s ) volcado hexadecimal (primeros 32 bytes): 00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................. rastreo inverso: seq_open+0x2a/0x80 full_proxy_open+0x167/0x1e0 do_dentry_open+0x1e1/0x3a0 path_openat+0x961/0xa20 do_filp_open+0xae/0x120 do_sys_openat2+0x216/0x2f0 do_sys_open+0x57/0x80 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 objeto sin referencia 0xffff93d419854000 (tamaño 4096): comm "cat", pid 23327, Jiffies 4624670141 (edad 495992,217 s) volcado hexadecimal (primeros 32 bytes) : 6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30 kfence-#250: 0x0 30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d 0000000754bda1 2- rastreo inverso: seq_read_iter+0x313/0x440 seq_read+ 0x14b/0x1a0 full_proxy_read+0x56/0x80 vfs_read+0xa5/0x1b0 ksys_read+0xa0/0xf0 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Creo que podemos reproducir fácilmente este problema con los siguientes comandos: cat /sys/kernel/ depurar/ kfence/objects echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak La memoria filtrada se asigna en la pila siguiente: do_syscall_64 do_sys_open do_dentry_open full_proxy_open seq_open ---> alloc seq_file vfs_read full_proxy_read seq_read seq_read_iter traverse - --> alloc seq_buf Y debería haberse liberado en el siguiente proceso: do_syscall_64 syscall_exit_to_user_mode exit_to_user_mode_prepare task_work_run ____fput __fput full_proxy_release ---> free aquí Sin embargo, la función de liberación correspondiente a file_operatives no está implementada en kfence. Como resultado, se produce una pérdida de memoria. Por tanto, la solución a este problema es implementar la función de liberación correspondiente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/hwpoison: borre MF_COUNT_INCREASED antes de volver a intentar get_any_page() Hulk Robot informó un pánico en put_page_testzero() al probar madvise() con MADV_SOFT_OFFLINE. El ERROR() se activa al volver a intentar get_any_page(). Esto se debe a que mantenemos el indicador MF_COUNT_INCREASED en el segundo intento pero el refcnt no aumenta. página volcada porque: VM_BUG_ON_PAGE(page_ref_count(page) == 0) ------------[ cortar aquí ]------------ ERROR del kernel en include/linux/mm .h:737! código de operación no válido: 0000 [#1] PREEMPT SMP CPU: 5 PID: 2135 Comm: sshd Contaminado: GB 5.16.0-rc6-dirty #373 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0- 1ubuntu1.1 01/04/2014 RIP: release_pages+0x53f/0x840 Seguimiento de llamadas: free_pages_and_swap_cache+0x64/0x80 tlb_flush_mmu+0x6f/0x220 unmap_page_range+0xe6c/0x12c0 unmap_single_vma+0x90/0x170 unmap _vmas+0xc4/0x180 salida_mmap+0xde/0x3a0 mmput+ 0xa3/0x250 do_exit+0x564/0x1470 do_group_exit+0x3b/0x100 __do_sys_exit_group+0x13/0x20 __x64_sys_exit_group+0x16/0x20 do_syscall_64+0x34/0x80 Entry_SYSCALL_64_after_hwframe+ 0x44/0xae Módulos vinculados en: ---[ end trace e99579b570fe0649 ]--- RIP: 0010:páginas_de_liberación+0x53f/0x840

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac80211: corrige el bloqueo en la ruta de error ieee80211_start_ap Necesitamos mantener local->mtx para liberar el contexto del canal, incluso codificado por lockdep_assert_held() allí. Arreglalo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: VMX: borre siempre vmx->fail en emulation_required Revierta un cambio relativamente reciente que establece vmx->fail si la vCPU está en L2 y emulation_required es verdadero, ya que ese comportamiento es completamente falso. Configurar vmx->fail y sintetizar una VM-Exit es contradictorio y incorrecto: (a) es imposible tener VM-Fail y VM-Exit (b) vmcs.EXIT_REASON no se modifica en VM-Fail (c) emulation_required se refiere al estado invitado y las comprobaciones del estado invitado son siempre salidas de VM, no fallas de VM. Para KVM específicamente, emulation_required se maneja antes de las salidas anidadas en __vmx_handle_exit(), por lo que configurar vmx->fail no tiene un efecto inmediato, es decir, las llamadas de KVM a handle_invalid_guest_state() y vmx->fail se ignoran. Configurar vmx->fail puede, en última instancia, generar una ADVERTENCIA en nested_vmx_vmexit() al desactivar la VM, ya que KVM nunca espera que vmx->fail se configure cuando L2 está activo, KVM siempre refleja esos errores en L1. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 21158 en arch/x86/kvm/vmx/nested.c:4548 nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547 Módulos vinculados en: CPU: 0 PID: 21158 Comm: syz-executor.1 No contaminado 5.16.0-rc3-syzkaller #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547 Código: <0f> 0b e9 2e f8 ff ff e8 57 b3 5d 00 0f 0b e9 00 f1 ff ff 89 e9 80 Seguimiento de llamadas: vmx_leave_nested arch/x86/kvm/vmx/nested.c:6220 [en línea] nested_vmx_free_vcpu+0x83/0xc0 arch/x86/kvm/vmx/nested.c: 330 vmx_free_vcpu+0x11f/0x2a0 arch/x86/kvm/vmx/vmx.c:6799 kvm_arch_vcpu_destroy+0x6b/0x240 arch/x86/kvm/x86.c:10989 kvm_vcpu_destroy+0x29/0x90 arch/x86/kvm/.. /. ./../virt/kvm/kvm_main.c:441 kvm_free_vcpus arch/x86/kvm/x86.c:11426 [en línea] kvm_arch_destroy_vm+0x3ef/0x6b0 arch/x86/kvm/x86.c:11545 kvm_destroy_vm arch/x86/ kvm/../../../virt/kvm/kvm_main.c:1189 [en línea] kvm_put_kvm+0x751/0xe40 arch/x86/kvm/../../../virt/kvm/kvm_main.c :1220 kvm_vcpu_release+0x53/0x60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3489 __fput+0x3fc/0x870 fs/file_table.c:280 task_work_run+0x146/0x1c0 kernel/ task_work.c:164 exit_task_work include/linux/task_work.h:32 [en línea] do_exit+0x705/0x24f0 kernel/exit.c:832 do_group_exit+0x168/0x2d0 kernel/exit.c:929 get_signal+0x1740/0x2120 kernel/señal .c:2852 arch_do_signal_or_restart+0x9c/0x730 arch/x86/kernel/signal.c:868 handle_signal_work kernel/entry/common.c:148 [en línea] exit_to_user_mode_loop kernel/entry/common.c:172 [en línea] exit_to_user_mode_prepare+0x191/ 0x220 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [en línea] syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 do_syscall_64+0x53/0xd0 arch/x86/entry/common. c:86 entrada_SYSCALL_64_after_hwframe+0x44/0xae