Vulnerabilidades

Proyecto Portal de Noticias phpgurukul V4.1 tiene una vulnerabilidad de eliminación arbitraria de archivos en remove_file.php. El parámetro file puede causar que cualquier archivo sea eliminado.

Proyecto de Portal de Noticias phpgurukul V4.1 es vulnerable a inyección SQL en check_availablity.php.

phpgurukul News Portal Project V4.1 tiene Vulnerabilidad de Carga de Archivos a través de upload.php, lo que permite la carga de archivos de cualquier formato al servidor sin autenticación de identidad.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: vfs: corregir condición de carrera en m_flags en vfs_cache<br /> <br /> ksmbd mantiene el estado de eliminación al cerrar y eliminación pendiente en ksmbd_inode-&amp;gt;m_flags. En vfs_cache.c, este campo es accedido bajo un bloqueo inconsistente: algunas rutas leen y modifican m_flags bajo ci-&amp;gt;m_lock mientras que otras lo hacen sin tomar el bloqueo en absoluto.<br /> <br /> Ejemplos:<br /> <br /> - ksmbd_query_inode_status() y __ksmbd_inode_close() usan ci-&amp;gt;m_lock al verificar o actualizar m_flags.<br /> - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete() y ksmbd_fd_set_delete_on_close() solían leer y modificar m_flags sin ci-&amp;gt;m_lock.<br /> <br /> Esto crea una potencial condición de carrera de datos en m_flags cuando múltiples hilos abren, cierran y eliminan el mismo archivo concurrentemente. En el peor de los casos, los bits de eliminación al cerrar y eliminación pendiente pueden perderse u observarse en un estado inconsistente, lo que lleva a semánticas de eliminación confusas (archivos que permanecen en el disco después de la eliminación al cerrar, o archivos que desaparecen mientras aún están en uso).<br /> <br /> Solucionarlo mediante:<br /> <br /> - Haciendo que ksmbd_query_inode_status() examine m_flags bajo ci-&amp;gt;m_lock después de liberar inode_hash_lock.<br /> - Añadiendo protección ci-&amp;gt;m_lock a todas las funciones auxiliares que leen o modifican m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()).<br /> - Manteniendo la protección ci-&amp;gt;m_lock existente en __ksmbd_inode_close(), y moviendo la eliminación real de unlink/xattr fuera del bloqueo.<br /> <br /> Esto unifica el bloqueo alrededor de m_flags y elimina la condición de carrera de datos mientras se preserva el comportamiento existente de eliminación al cerrar.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> KVM: No permitir la alternancia de KVM_MEM_GUEST_MEMFD en un memslot existente<br /> <br /> Rechazar los intentos de deshabilitar KVM_MEM_GUEST_MEMFD en un memslot que fue creado inicialmente con una vinculación guest_memfd, ya que KVM no soporta la alternancia de KVM_MEM_GUEST_MEMFD en memslots existentes. KVM impide habilitar KVM_MEM_GUEST_MEMFD, pero no impide borrar el indicador.<br /> <br /> La falta de rechazo del nuevo memslot resulta en un uso después de liberación debido a que KVM no se desvincula de la instancia guest_memfd. La desvinculación en un cambio de FLAGS_ONLY es bastante sencilla, y puede/será realizada como una medida de endurecimiento (en anticipación de que KVM soporte el registro de cambios (dirty logging) en guest_memfd en algún momento), pero corregir el uso después de liberación solo abordaría el síntoma inmediato.<br /> <br /> ==================================================================<br /> ERROR: KASAN: uso después de liberación de slab en kvm_gmem_release+0x362/0x400 [kvm]<br /> Escritura de tamaño 8 en la dirección ffff8881111ae908 por la tarea repro/745<br /> <br /> CPU: 7 UID: 1000 PID: 745 Comm: repro No contaminado 6.18.0-rc6-115d5de2eef3-next-kasan #3 NINGUNO<br /> Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Traza de llamada:<br /> <br /> dump_stack_lvl+0x51/0x60<br /> print_report+0xcb/0x5c0<br /> kasan_report+0xb4/0xe0<br /> kvm_gmem_release+0x362/0x400 [kvm]<br /> __fput+0x2fa/0x9d0<br /> task_work_run+0x12c/0x200<br /> do_exit+0x6ae/0x2100<br /> do_group_exit+0xa8/0x230<br /> __x64_sys_exit_group+0x3a/0x50<br /> x64_sys_call+0x737/0x740<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f581f2eac31<br /> <br /> <br /> Asignado por la tarea 745 en la CPU 6 a las 9.746971s:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x13/0x50<br /> __kasan_kmalloc+0x77/0x90<br /> kvm_set_memory_region.part.0+0x652/0x1110 [kvm]<br /> kvm_vm_ioctl+0x14b0/0x3290 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Liberado por la tarea 745 en la CPU 6 a las 9.747467s:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x13/0x50<br /> __kasan_save_free_info+0x37/0x50<br /> __kasan_slab_free+0x3b/0x60<br /> kfree+0xf5/0x440<br /> kvm_set_memslot+0x3c2/0x1160 [kvm]<br /> kvm_set_memory_region.part.0+0x86a/0x1110 [kvm]<br /> kvm_vm_ioctl+0x14b0/0x3290 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> svcrdma: usar rc_pageoff para el desplazamiento de bytes de memcpy<br /> <br /> svc_rdma_copy_inline_range añadía rc_curpage (índice de página) a la base de la página en lugar del desplazamiento de bytes rc_pageoff. Usar rc_pageoff para que las copias caigan dentro de la página actual.<br /> <br /> Encontrado por ZeroPath (https://zeropath.com)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipvs: corrección de desreferencia de puntero nulo ipv4 en la ruta de error de enrutamiento<br /> <br /> La ruta de código IPv4 en __ip_vs_get_out_rt() llama a dst_link_failure() sin asegurar que skb-&amp;gt;dev esté configurado, lo que lleva a una desreferencia de puntero NULO en fib_compute_spec_dst() cuando ipv4_link_failure() intenta enviar mensajes ICMP de destino inalcanzable.<br /> <br /> El problema surgió después de que el commit ed0de45a1008 (&amp;#39;ipv4: recompilar opciones ip en ipv4_link_failure&amp;#39;) comenzó a llamar a __ip_options_compile() desde ipv4_link_failure(). Esta ruta de código finalmente llama a fib_compute_spec_dst() que desreferencia skb-&amp;gt;dev. Se intentó corregir la desreferencia de skb-&amp;gt;dev NULO en el commit 0113d9c9d1cc (&amp;#39;ipv4: corregir desreferencia nula en ipv4_link_failure&amp;#39;), pero solo abordó la desreferencia inmediata de dev_net(skb-&amp;gt;dev) mediante el uso de un dispositivo de respaldo. La corrección fue incompleta porque fib_compute_spec_dst() más adelante en la cadena de llamadas todavía accede a skb-&amp;gt;dev directamente, que permanece NULO cuando IPVS llama a dst_link_failure().<br /> <br /> El fallo ocurre cuando:<br /> 1. IPVS procesa un paquete en modo NAT con un destino mal configurado<br /> 2. La búsqueda de ruta falla en __ip_vs_get_out_rt() antes de establecer una ruta<br /> 3. La ruta de error llama a dst_link_failure(skb) con skb-&amp;gt;dev == NULO<br /> 4. ipv4_link_failure() ? ipv4_send_dest_unreach() ? __ip_options_compile() ? fib_compute_spec_dst()<br /> 5. fib_compute_spec_dst() desreferencia skb-&amp;gt;dev NULO<br /> <br /> Aplicar la misma corrección utilizada para IPv6 en el commit 326bf17ea5d4 (&amp;#39;ipvs: corregir pánico por ruta inalcanzable ipv6&amp;#39;): establecer skb-&amp;gt;dev desde skb_dst(skb)-&amp;gt;dev antes de llamar a dst_link_failure().<br /> <br /> KASAN: desreferencia de puntero nulo en el rango [0x0000000000000328-0x000000000000032f]<br /> CPU: 1 PID: 12732 Comm: syz.1.3469 No contaminado 6.6.114 #2<br /> RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233<br /> RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285<br /> Rastro de Llamada:<br /> <br /> spec_dst_fill net/ipv4/ip_options.c:232<br /> spec_dst_fill net/ipv4/ip_options.c:229<br /> __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330<br /> ipv4_send_dest_unreach net/ipv4/route.c:1252<br /> ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265<br /> dst_link_failure include/net/dst.h:437<br /> __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412<br /> ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> io_uring: corregir fuga de filename en __io_openat_prep()<br /> <br /> __io_openat_prep() asigna una estructura filename usando getname(). Sin embargo, para la condición de que el archivo esté instalado en la tabla de archivos fija, así como de tener la bandera O_CLOEXEC establecida, la función retorna prematuramente. En ese punto, la solicitud no tiene la bandera REQ_F_NEED_CLEANUP establecida. Debido a esto, la memoria para la estructura filename recién asignada no se limpia, causando una fuga de memoria.<br /> <br /> Solucione esto estableciendo la bandera REQ_F_NEED_CLEANUP para la solicitud justo después de la llamada exitosa a getname(), de modo que cuando la solicitud sea desmantelada, el filename será limpiado, junto con otros recursos que necesiten limpieza.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: ets: Eliminar la clase drr de la lista activa si cambia a estricta<br /> <br /> Siempre que un usuario emite un comando de cambio de qdisc ets, transformando una clase drr en una estricta, el código ets no está verificando si esa clase estaba en la lista activa y eliminándola. Esto significa que, si un usuario cambia una clase estricta (que estaba en la lista activa) de nuevo a una drr, esa clase se añadirá dos veces a la lista activa [1].<br /> <br /> Hacer esto con los siguientes comandos:<br /> <br /> tc qdisc add dev lo root handle 1: ets bands 2 strict 1<br /> tc qdisc add dev lo parent 1:2 handle 20: \<br /> tbf rate 8bit burst 100b latency 1s<br /> tc filter add dev lo parent 1: basic classid 1:2<br /> ping -c1 -W0.01 -s 56 127.0.0.1<br /> tc qdisc change dev lo root handle 1: ets bands 2 strict 2<br /> tc qdisc change dev lo root handle 1: ets bands 2 strict 1<br /> ping -c1 -W0.01 -s 56 127.0.0.1<br /> <br /> Activará el siguiente splat con la depuración de lista activada:<br /> <br /> [ 59.279014][ T365] ------------[ cut here ]------------<br /> [ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0.<br /> [ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220<br /> [ 59.280860][ T365] Modules linked in:<br /> [ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary)<br /> [ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220<br /> [ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 &amp;lt;0f&amp;gt; 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44<br /> ...<br /> [ 59.288812][ T365] Call Trace:<br /> [ 59.289056][ T365] <br /> [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80<br /> [ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0<br /> [ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10<br /> [ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240<br /> [ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10<br /> [ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.292313][ T365] ? trace_contention_end+0xc8/0x110<br /> [ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0<br /> <br /> Solucione esto siempre verificando y eliminando una clase ets de la lista activa al cambiarla a estricta.<br /> <br /> [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/mlx5: fw_tracer, Validar parámetros de cadena de formato<br /> <br /> Añadir validación para los parámetros de cadena de formato en el trazador de firmware para prevenir posibles vulnerabilidades de seguridad y fallos causados por cadenas de formato malformadas recibidas del firmware.<br /> <br /> El trazador de firmware recibe cadenas de formato del firmware del dispositivo y las utiliza para formatear mensajes de traza. Sin una validación adecuada, un firmware defectuoso podría proporcionar cadenas de formato con especificadores de formato inválidos (p. ej., %s, %p, %n) que podrían provocar fallos u otro comportamiento indefinido.<br /> <br /> Añadir mlx5_tracer_validate_params() para validar que todos los especificadores de formato en las cadenas de traza estén limitados a formatos seguros de entero/hexadecimal (p. ej., %x, %d, %i, %u, %llx, %lx, etc.). Rechazar cadenas que contengan otros tipos de formato que podrían utilizarse para acceder a memoria arbitraria o causar fallos.<br /> Las cadenas de formato inválidas se añaden a la salida de traza para visibilidad con el prefijo &amp;#39;BAD_FORMAT: &amp;#39;.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: corrección de uso después de liberación en ksmbd_tree_connect_put bajo concurrencia<br /> <br /> Bajo alta concurrencia, un objeto de conexión de árbol (tcon) es liberado en una ruta de desconexión mientras otra ruta aún mantiene una referencia y posteriormente ejecuta *_put()/write sobre él.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: iris: Añadir comprobación de cordura para detener la transmisión<br /> <br /> Añadir comprobación de cordura en iris_vb2_stop_streaming. Si inst-&amp;gt;state ya es IRIS_INST_ERROR, deberíamos omitir la operación stream_off porque aún enviaría paquetes al firmware.<br /> <br /> En iris_kill_session, inst-&amp;gt;state se establece en IRIS_INST_ERROR y se ejecuta session_close, lo que liberará kfree(inst_hfi_gen2-&amp;gt;packet). Si stop_streaming se llama después, provocará un fallo.<br /> <br /> [bod: eliminar qcom del título del parche]