Vulnerabilidades

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 /> scsi: Revertir "scsi: qla2xxx: Realizar la finalización de comandos sin bloqueo en la ruta de aborto"<br /> <br /> Esto revierte el commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.<br /> <br /> El commit que se revierte añadió código a __qla2x00_abort_all_cmds() para llamar a sp-&amp;gt;done() sin mantener un spinlock. Pero a diferencia del código anterior debajo de él, este nuevo código no verificó sp-&amp;gt;cmd_type y simplemente asumió TYPE_SRB, lo que resulta en un salto a un puntero inválido en modo objetivo con TYPE_TGT_CMD:<br /> <br /> qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success<br /> 0000000009f7a79b<br /> qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h<br /> mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.<br /> qla2xxx [0000:65:00.0]-d01e:8: -&amp;gt; fwdump no buffer<br /> qla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event<br /> 0x8002 occurred<br /> qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -<br /> ha=0000000058183fda.<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PF: supervisor instruction fetch in kernel mode<br /> PF: error_code(0x0010) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0010 [#1] SMP<br /> CPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1<br /> Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206<br /> RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000<br /> RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0<br /> RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045<br /> R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40<br /> R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400<br /> FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die+0x4d/0x8b<br /> ? page_fault_oops+0x91/0x180<br /> ? trace_buffer_unlock_commit_regs+0x38/0x1a0<br /> ? exc_page_fault+0x391/0x5e0<br /> ? asm_exc_page_fault+0x22/0x30<br /> __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst]<br /> qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst]<br /> qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst]<br /> qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst]<br /> qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst]<br /> kthread+0xa8/0xd0<br /> <br /> <br /> Luego el commit 4475afa2646d (&amp;#39;scsi: qla2xxx: Completar comando temprano dentro del bloqueo&amp;#39;) añadió el spinlock de nuevo, porque no tener el bloqueo causó una condición de carrera y un fallo. Pero qla2x00_abort_srb() en el switch de abajo ya verifica qla2x00_chip_is_down() y lo maneja de la misma manera, por lo que el código encima del switch es ahora redundante y sigue siendo defectuoso en modo objetivo. Elimínelo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: dvb-usb: dtv5100: corrección de acceso fuera de límites en dtv5100_i2c_msg()<br /> <br /> El valor de rlen es un valor controlado por el usuario, pero dtv5100_i2c_msg() no verifica el tamaño del valor de rlen. Por lo tanto, si se establece en un valor mayor que sizeof(st-&amp;gt;data), ocurre una vulnerabilidad de acceso fuera de límites para st-&amp;gt;data.<br /> <br /> Por lo tanto, necesitamos añadir una verificación de rango adecuada para prevenir esta vulnerabilidad.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ext4: xattr: corregir desreferencia de puntero nulo en ext4_raw_inode()<br /> <br /> Si ext4_get_inode_loc() falla (p. ej., si devuelve -EFSCORRUPTED), iloc.bh permanecerá establecido en NULL. Dado que ext4_xattr_inode_dec_ref_all() carece de comprobación de errores, esto conducirá a una desreferencia de puntero nulo en ext4_raw_inode(), llamada justo después de ext4_get_inode_loc().<br /> <br /> Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fuse: corregir interbloqueo de recuperación de lectura anticipada<br /> <br /> El commit e26ee4efbc79 (&amp;#39;fuse: asignar ff-&amp;gt;release_args solo si se necesita la liberación&amp;#39;) omite la asignación de ff-&amp;gt;release_args si el servidor no implementa open. Sin embargo, al hacerlo, fuse_prepare_release() ahora omite tomar la referencia en el inodo, lo que hace posible que un inodo sea desalojado del dcache mientras hay solicitudes de lectura anticipada en curso. Esto causa un interbloqueo si el servidor activa la recuperación mientras atiende la solicitud de lectura anticipada y la recuperación intenta desalojar el inodo del archivo que se está leyendo anticipadamente. Dado que el folio está bloqueado durante la lectura anticipada, cuando la recuperación desaloja el inodo fuse y fuse_evict_inode() intenta eliminar todos los folios asociados con el inodo de la caché de páginas (truncate_inode_pages_range()), la recuperación se bloqueará para siempre esperando el bloqueo ya que la lectura anticipada no puede liberar el bloqueo porque está a su vez bloqueada en la recuperación:<br /> <br /> &amp;gt;&amp;gt;&amp;gt; traza_de_pila(1504735)<br /> folio_wait_bit_common (mm/filemap.c:1308:4)<br /> folio_lock (./include/linux/pagemap.h:1052:3)<br /> truncate_inode_pages_range (mm/truncate.c:336:10)<br /> fuse_evict_inode (fs/fuse/inode.c:161:2)<br /> evict (fs/inode.c:704:3)<br /> dentry_unlink_inode (fs/dcache.c:412:3)<br /> __dentry_kill (fs/dcache.c:615:3)<br /> shrink_kill (fs/dcache.c:1060:12)<br /> shrink_dentry_list (fs/dcache.c:1087:3)<br /> prune_dcache_sb (fs/dcache.c:1168:2)<br /> super_cache_scan (fs/super.c:221:10)<br /> do_shrink_slab (mm/shrinker.c:435:9)<br /> shrink_slab (mm/shrinker.c:626:10)<br /> shrink_node (mm/vmscan.c:5951:2)<br /> shrink_zones (mm/vmscan.c:6195:3)<br /> do_try_to_free_pages (mm/vmscan.c:6257:3)<br /> do_swap_page (mm/memory.c:4136:11)<br /> handle_pte_fault (mm/memory.c:5562:10)<br /> handle_mm_fault (mm/memory.c:5870:9)<br /> do_user_addr_fault (arch/x86/mm/fault.c:1338:10)<br /> handle_page_fault (arch/x86/mm/fault.c:1481:3)<br /> exc_page_fault (arch/x86/mm/fault.c:1539:2)<br /> asm_exc_page_fault+0x22/0x27<br /> <br /> Solucione este interbloqueo asignando ff-&amp;gt;release_args y tomando la referencia en el inodo al preparar el archivo para su liberación, incluso si el servidor no implementa open. La referencia del inodo se eliminará cuando se elimine la última referencia en el archivo fuse (ver fuse_file_put() -&amp;gt; fuse_release_end()).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Entrada: alps - corrige errores de uso después de liberación causados por dev3_register_work<br /> <br /> El elemento de trabajo retrasado dev3_register_work se inicializa dentro de alps_reconnect() y se programa al recibir el primer paquete PS/2 &amp;#39;bare&amp;#39; de un dispositivo PS/2 externo conectado al touchpad ALPS. Durante la desconexión del dispositivo, la implementación original llama a flush_workqueue() en psmouse_disconnect() para asegurar la finalización de dev3_register_work. Sin embargo, la flush_workqueue() en psmouse_disconnect() solo bloquea y espera por elementos de trabajo que ya estaban en cola en la workqueue antes de su invocación. Cualquier elemento de trabajo enviado después de que se llama a flush_workqueue() no se incluye en el conjunto de tareas que la operación de &amp;#39;flush&amp;#39; espera. Esto significa que después de que flush_workqueue() ha terminado de ejecutarse, el dev3_register_work aún podría programarse. Aunque el estado de psmouse se establece en PSMOUSE_CMD_MODE en psmouse_disconnect(), la programación de dev3_register_work permanece inalterada.<br /> <br /> La condición de carrera puede ocurrir de la siguiente manera:<br /> <br /> CPU 0 (ruta de limpieza) | CPU 1 (trabajo retrasado)<br /> psmouse_disconnect() |<br /> psmouse_set_state() |<br /> flush_workqueue() | alps_report_bare_ps2_packet()<br /> alps_disconnect() | psmouse_queue_work()<br /> kfree(priv); // LIBERAR | alps_register_bare_ps2_mouse()<br /> | priv = container_of(work...); // USAR<br /> | priv-&amp;gt;dev3 // USAR<br /> <br /> Añadir disable_delayed_work_sync() en alps_disconnect() para asegurar que dev3_register_work se cancele correctamente y se impida su ejecución después de que la estructura alps_data haya sido desasignada.<br /> <br /> Este error es identificado por análisis estático.

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]

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