Vulnerabilidades

Se encontró una vulnerabilidad clasificada como crítica en SourceCodester Web-based Pharmacy Product Management System 1.0. Esta vulnerabilidad afecta al código desconocido del archivo /search/search_stock.php. La manipulación del argumento "Nombre" provoca una inyección SQL. El ataque puede iniciarse remotamente. Se ha hecho público el exploit y puede que sea utilizado.

Se ha detectado una vulnerabilidad clasificada como crítica en SourceCodester Web-based Pharmacy Product Management System 1.0. Este problema afecta a un procesamiento desconocido del archivo /edit-product.php. La manipulación del ID del argumento provoca una inyección SQL. El ataque podría iniciarse remotamente. Se ha hecho público el exploit y puede que sea utilizado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq/amd-pstate: Agregar comprobación ptr NULL faltante en amd_pstate_update Verifique si la política es NULL antes de desreferenciarla en amd_pstate_update.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watch_queue: corrección de la discrepancia en la contabilidad de la tubería. Actualmente, watch_queue_set_size() modifica los búferes de la tubería cargados a user->pipe_bufs sin actualizar pipe->nr_accounted en la propia tubería, debido a la prueba if (!pipe_has_watch_queue()) en pipe_resize_ring(). Esto significa que, cuando la tubería se libera finalmente, se decrementa user->pipe_bufs en un valor distinto al que se le había cargado, lo que podría provocar un desbordamiento. Esto, a su vez, puede provocar que las pruebas too_many_pipe_buffers_soft() posteriores fallen con -EPERM. Para remediar esto, tenga en cuenta explícitamente el uso de la tubería en watch_queue_set_size() para que coincida con el número establecido mediante account_pipe_buffers() (no está claro por qué watch_queue_set_size() no actualiza nr_accounted; puede deberse a un exceso de aprovisionamiento intencional en watch_queue_set_size()).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: temporizador: No se utiliza register_mutex con copy_from/to_user(). El infame bloqueo mmap utilizado en copy_from/to_user() puede ser problemático cuando se invoca dentro de otro mutex, ya que podría provocar interbloqueos. En el caso del código del temporizador ALSA, el patrón incorrecto se encuentra en guard(mutex)(&register_mutex) que cubre copy_from/to_user(), que se introdujo por error al convertir a guard() y que ya se había solucionado cuidadosamente en el pasado. Este parche corrige estos problemas simplemente sacando copy_from/to_user() del bloqueo mutex de registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RISC-V: KVM: Desmontaje de bits específicos de RISCV después de kvm_exit. Durante la eliminación de un módulo, kvm_exit invoca una llamada de desactivación específica de la arquitectura, que deshabilita AIA. Sin embargo, al invocar aia_exit antes de kvm_exit, se genera la siguiente advertencia. El módulo del kernel KVM no se puede insertar posteriormente debido a un estado inconsistente de IRQ. [25469.031389] ¡IRQ 31 por CPU sigue habilitado en CPU0! [25469.031732] ADVERTENCIA: CPU: 3 PID: 943 en kernel/irq/manage.c:2476 __free_percpu_irq+0xa2/0x150 [25469.031804] Módulos vinculados: kvm(-) [25469.031848] CPU: 3 UID: 0 PID: 943 Comm: rmmod No contaminado 6.14.0-rc5-06947-g91c763118f47-dirty #2 [25469.031905] Nombre del hardware: riscv-virtio,qemu (DT) [25469.031928] epc : __free_percpu_irq+0xa2/0x150 [25469.031976] ra : __free_percpu_irq+0xa2/0x150 [25469.032197] epc : ffffffff8007db1e ra : ffffffff8007db1e sp : ff2000000088bd50 [25469.032241] gp : ffffffff8131cef8 tp : ff60000080b96400 t0 : ff2000000088baf8 [25469.032285] t1 : fffffffffffffffc t2 : 5249207570637265 s0 : ff2000000088bd90 [25469.032329] s1: ff60000098b21080 a0: 037d527a15eb4f00 a1: 037d527a15eb4f00 [25469.032372] a2: 0000000000000023 a3: 0000000000000001 a4 : ffffffff8122dbf8 [25469.032410] a5 : 0000000000000fff a6 : 00000000000000000 a7 : ffffffff8122dc10 [25469.032448] s2 : ff60000080c22eb0 s3: 0000000200000022 s4: 000000000000001f [25469.032488] s5: ff60000080c22e00 s6: ffffffff80c351c0 s7: 0000000000000000 [25469.032582] s8: 0000000000000003 s9: 000055556b7fb490 s10: 00007ffff0e12fa0 [25469.032621] s11: 00007ffff0e13e9a t3: ffffffff81354ac7 t4: ffffffff81354ac7 [25469.032664] t5: ffffffff81354ac8 t6: ffffffff81354ac7 [25469.032698] estado: 0000000200000100 dirección incorrecta: ffffffff8007db1e causa: 0000000000000003 [25469.032738] [] __free_percpu_irq+0xa2/0x150 [25469.032797] [] free_percpu_irq+0x30/0x5e [25469.032856] [] kvm_riscv_aia_exit+0x40/0x42 [kvm] [25469.033947] [] módulo_limpieza+0x10/0x32 [kvm] [25469.035300] [] __riscv_sys_delete_module+0x18e/0x1fc [25469.035374] [] controlador_de_llamadas_al_sistema+0x3a/0x46 [25469.035456] [] do_trap_ecall_u+0x72/0x134 [25469.035536] [] handle_exception+0x148/0x156 Invoca aia_exit y otras funciones de limpieza específicas de la arquitectura después de kvm_exit para que deshabilitar tenga la oportunidad de ser llamado primero antes de salir.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: actualizar la lista de canales en el notificador de registros en lugar del trabajador de registros. Actualmente, cuando ath11k obtiene una nueva lista de canales, esta se procesa según los siguientes pasos: 1. Actualizar la nueva lista de canales a cfg80211 y poner en cola reg_work. 2. cfg80211 gestiona la nueva lista de canales durante reg_work. 3. Actualizar la lista de canales gestionada de cfg80211 al firmware mediante ath11k_reg_update_chan_list(). Sin embargo, ath11k ejecutará inmediatamente el paso 3 después de poner en cola reg_work. Como el paso 2 es asincrónico, es posible que cfg80211 no haya terminado de manejar la nueva lista de canales, lo que puede generar un error de escritura fuera de los límites: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0 Se debe asegurar que el paso 2 se haya realizado completamente antes de ejecutar el paso 3. Por lo tanto, Wen planteó patch[1]. Cuando se activa el indicador NL80211_REGDOM_SET_BY_DRIVER, cfg80211 notificará a ath11k una vez finalizado el paso 2. Por lo tanto, al activar el indicador NL80211_REGDOM_SET_BY_DRIVER, cfg80211 notificará a ath11k una vez finalizado el paso 2. En este momento, no se producirá ningún error de KASAN durante la ejecución del paso 3. [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/ Probado en: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: cuota: corrección para evitar advertencias en dquot_writeback_dquots() F2FS-fs (dm-59): checkpoint=enable tiene algunos datos no escritos. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 6 PID: 8013 en fs/quota/dquot.c:691 dquot_writeback_dquots+0x2fc/0x308 pc : dquot_writeback_dquots+0x2fc/0x308 lr : f2fs_quota_sync+0xcc/0x1c4 Rastreo de llamadas: dquot_writeback_dquots+0x2fc/0x308 f2fs_quota_sync+0xcc/0x1c4 f2fs_write_checkpoint+0x3d4/0x9b0 f2fs_issue_checkpoint+0x1bc/0x2c0 f2fs_sync_fs+0x54/0x150 f2fs_do_sync_file+0x2f8/0x814 __f2fs_ioctl+0x1960/0x3244 f2fs_ioctl+0x54/0xe0 __arm64_sys_ioctl+0xa8/0xe4 evolve_syscall+0x58/0x114 el punto de control y f2fs_remount pueden competir como se muestra a continuación, lo que activa una advertencia en dquot_writeback_dquots(). remot de escritura atómica - do_remount - down_write(&sb->s_umount); - f2fs_remount - ioctl - f2fs_do_sync_file - f2fs_sync_fs - f2fs_write_checkpoint - block_operations - locking = down_read_trylock(&sbi->sb->s_umount) : no se pudo bloquear debido a que el bloqueo de escritura fue mantenido por el remot - up_write(&sb->s_umount); - f2fs_quota_sync - dquot_writeback_dquots - WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount)) : activa una advertencia porque el bloqueo s_umount se desbloqueó al volver a montar Si el punto de control proviene de mount/umount/remount/freeze/quotactl, el llamador del punto de control ya ha mantenido el bloqueo s_umount, llamar a dquot_writeback_dquots() en el contexto debería ser seguro. Así que grabemos la tarea en sbi->umount_lock_holder, para que el punto de control pueda saber si el bloqueo se ha mantenido en el contexto o no al verificar la corriente con él. Además, para no tergiversar la llamada del punto de control, no deberíamos permitir que se active el punto de control asíncrono para esos llamadores: mount/umount/remount/freeze/quotactl.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dlm: impide NPD al escribir un valor positivo en event_done. do_uevent devuelve el valor escrito en event_done. En caso de ser un valor positivo, new_lockspace desharía todo el trabajo y no se establecería el espacio de bloqueo. Sin embargo, __dlm_new_lockspace trataría ese valor positivo como un éxito debido a el commit 8511a2728ab8 ("dlm: corrige el recuento de uso con múltiples uniones"). Posteriormente, device_create_lockspace pasaría ese espacio de bloqueo nulo a dlm_find_lockspace_local, lo que provocaría una desreferencia de puntero nulo. Tratar estos valores positivos como éxitos evita el problema. Dado que esto ha estado roto durante tanto tiempo, es improbable que esto altere las expectativas del espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar el pánico cuando falla la fallocation para el archivo PIN syzbot informa un error de f2fs como el siguiente: ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 No contaminado 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [en línea] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Rastreo de llamadas: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [en línea] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f La asignación simultánea de archivos PIN puede agotar la sección libre, lo que genera un pánico en get_new_segment(). Expandamos la cobertura del bloqueo de PIN_SEM para incluir f2fs_gc() y así asegurarnos de recuperar suficiente espacio libre para la siguiente asignación. Además, implementemos los siguientes cambios para mejorar la gestión de rutas de error: - Llamar a f2fs_bug_on() solo en rutas de asignación que no sean archivos PIN en get_new_segment(). - Llamar a reset_curseg_fields() para restablecer todos los campos de curseg en new_curseg().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: térmica: int340x: Añadir comprobación de valores nulos para adev. No todos los dispositivos tienen un nodo auxiliar ACPI, por lo que adev podría ser nulo. Esto es similar a el commit cd2fd6eab480 ("plataforma/x86: int3472: Comprobar si adev == NULL"). Añadir una comprobación para comprobar si adev no está configurado y devolver -ENODEV en ese caso para evitar una posible desreferencia de puntero nulo en int3402_thermal_probe(). Cabe destacar que, en el mismo directorio, int3400_thermal_probe() cuenta con dicha comprobación. [rjw: Edición del tema, correcciones añadidas]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: Borrar la indicación de afinidad antes de llamar a ath11k_pcic_free_irq() en la ruta de error. Si el controlador utiliza una IRQ compartida debido a una limitación de la plataforma, la indicación de afinidad de IRQ se establece justo después de la asignación de vectores IRQ en ath11k_pci_alloc_msi(). Esto no causa ningún problema a menos que una de las funciones que solicita la IRQ falle e intente liberarla. Esto da como resultado la siguiente advertencia: ADVERTENCIA: CPU: 7 PID: 349 en kernel/irq/manage.c:1929 free_irq+0x278/0x29c Rastreo de llamadas: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc La advertencia se debe a que no se borra la sugerencia de afinidad antes de liberar las IRQ. Por lo tanto, para solucionar este problema, borre la sugerencia de afinidad de IRQ antes de llamar a ath11k_pcic_free_irq() en la ruta de error. La afinidad se borrará una vez más más adelante en la ruta de error debido a la organización del código, pero eso no hace daño. Probado en: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1