Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Se corrige el manejo incorrecto de refcount en ice_dpll_init_rclk_pins() Este parche soluciona un problema de manejo de recuento de referencias en la función ice_dpll_init_rclk_pins(). La función llama a ice_dpll_get_pins(), que incrementa el recuento de referencias de los recursos relevantes. Sin embargo, si se cumple la condición WARN_ON((!vsi || !vsi->netdev)), la función actualmente devuelve un error sin liberar correctamente los recursos adquiridos por ice_dpll_get_pins(), lo que lleva a una pérdida de recuento de referencias. Para resolver esto, la comprobación se ha movido a la parte superior de la función. Esto garantiza que la función verifique el estado antes de que se adquieran recursos, lo que evita la necesidad de una gestión de recursos adicional en la ruta de error. Este error fue identificado por una herramienta de análisis estático experimental desarrollada por nuestro equipo. La herramienta se especializa en analizar operaciones de recuento de referencias y detectar posibles problemas donde los recursos no se administran correctamente. En este caso, la herramienta marcó la operación de liberación faltante como un problema potencial, lo que llevó al desarrollo de este parche.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: Eliminar la entrada LED de la lista de LED al anular el registro El commit c938ab4da0eb ("net: phy: Eliminar manualmente los LED para garantizar el orden correcto") corrigió correctamente un problema con el uso de devm_ pero no eliminó la entrada LED de la lista de LED. Esto causa pánico del kernel en un escenario específico donde el puerto para el PHY se desactiva y activa y se elimina el kmod para el PHY. Al desactivar el puerto la primera vez, los LED asociados se anulan correctamente el registro. El kmod asociado para el PHY ahora se elimina. El kmod ahora se agrega nuevamente y el puerto ahora se activa, los LED asociados se registran nuevamente. Al desactivar el puerto nuevamente por segunda vez después de estos pasos, la lista de LED ahora tiene 4 elementos. Con los primeros 2 ya anulados previamente y los 2 nuevos registrados nuevamente. Esto causa un pánico del kernel ya que los primeros 2 elementos deberían haberse eliminado. Arregle esto eliminando correctamente el elemento cuando el LED no está registrado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: fnic: mover la inicialización de flush_work fuera del bloque if Después de el commit 379a58caa199 ("scsi: fnic: mover fnic_fnic_flush_tx() a una cola de trabajo"), puede suceder que un elemento de trabajo se envíe a una cola de trabajo no inicializada. Esto puede tener el efecto de que el elemento que se está poniendo en cola nunca se ponga en cola y cualquier acción posterior que dependa de él no se lleve a cabo. Se observa la siguiente advertencia mientras se carga el controlador fnic: kernel: ADVERTENCIA: CPU: 11 PID: 0 en ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: Se ha observado que esto puede interrumpir el redescubrimiento de dispositivos Fibre Channel después de un fallo temporal de la estructura. Este parche lo soluciona moviendo la inicialización de la cola de trabajo fuera de un bloque if en fnic_probe().

Online Clinic Management System v1.0 contenía una vulnerabilidad de inyección SQL a través del parámetro id en /success/editp.php?action=edit.

Un problema en DCME-320-L <=9.3.2.114 permite a un atacante remoto ejecutar código arbitrario a través del componente log_u_umount.php.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kthread: unpark solo kthread aparcado Llamar a kthread unparking incondicionalmente es mayormente inofensivo cuando el kthread ya está desestacionado. Luego, la activación simplemente se ignora porque el objetivo no está en estado TASK_PARKED. Sin embargo, si el kthread es por CPU, la activación está precedida por una llamada a kthread_bind() que espera que la tarea esté inactiva y en estado TASK_PARKED, lo que obviamente no es el caso si está desestacionada. Como resultado, llamar a kthread_stop() en un kthread por CPU no estacionado activa esta advertencia: ADVERTENCIA: CPU: 0 PID: 11 en kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [en línea] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [en línea] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Solucione esto omitiendo el desestacionamiento innecesario mientras Detener un kthread.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: device-dax: alineación correcta de pgoff en dax_set_mapping() pgoff debe alinearse usando ALIGN_DOWN() en lugar de ALIGN(). De lo contrario, vmf->address no alineado con fault_size se alineará con la siguiente alineación, lo que puede provocar que El fallo de memoria obtenga la dirección incorrecta. Es una situación sutil que solo se puede observar en page_mapped_in_vma() después de que dev_dax_huge_fault gestione El fallo de página. Generalmente, hay pocas posibilidades de realizar page_mapped_in_vma en la página de dev-dax a menos que se trate de una inyección de error específica en el dispositivo dax para activar un MCE (fallo de memoria). En ese caso, se activará page_mapped_in_vma() para determinar qué tarea está accediendo a la dirección de fallo y matar esa tarea al final. Usamos un dispositivo dax desarrollado por nosotros mismos (que es un mapeo alineado de 2M) para realizar una inyección de error en una dirección aleatoria. Resultó que el error inyectado en una dirección no alineada a 2M estaba causando un MCE interminable hasta que surgió el pánico. Debido a que page_mapped_in_vma() seguía generando una dirección incorrecta y la tarea que accedía a la dirección fallida nunca se finalizaba correctamente: [3783.719419] Error de memoria: 0x200c9742: acción de recuperación para la página dax: recuperada [3784.049006] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3784.049190] Error de memoria: 0x200c9742: acción de recuperación para la página dax: recuperada [3784.448042] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3784.448186] Error de memoria: 0x200c9742: acción de recuperación para la página dax: recuperada [3784.792026] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3784.792179] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3785.162502] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3785.162633] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3785.461116] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [3785.461247] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3785.764730] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [3785.764859] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3786.042128] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [3786.042259] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3786.464293] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [3786.464423] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [3786.818090] mce: Error de memoria de hardware sin corregir en acceso de usuario en 200c9742380 [ 3786.818217] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado [ 3787.085297] mce: Error de memoria de hardware sin corregir en el acceso de usuario en 200c9742380 [ 3787.085424] Error de memoria: 0x200c9742: acción de recuperación para la página dax: Recuperado Nos llevó varias semanas localizar este problema, pero finalmente usamos bpftrace para rastrear El fallo de página y la dirección mce e identificamos el problema con éxito. Joao agregó: ; Es probable que nunca lo reproduzcamos en producción porque siempre fijamos : las regiones device-dax en la alineación de región que proporcionan (Qemu hace : de manera similar con prealloc en la memoria respaldada por hugetlb/archivo). Creo que este error requiere que toquemos regiones del dispositivo DAX *no fijadas* que no estén alineadas con la alineación seleccionada del dispositivo DAX (tamaño de página, es decir, 4K/2M/1G)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Corrige un bucle inseguro en la lista El kernel puede bloquearse al eliminar una familia genetlink si aún hay oyentes para esa familia: Oops: Acceso al kernel al área incorrecta, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Rastreo de llamadas: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Cambia el bucle inseguro en la lista a uno seguro, porque dentro del bucle hay una eliminación de elementos de esta lista.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: wd33c93: No usar valor scsi_pointer obsoleto Se introdujo una regresión con el commit dbb2da557a6a ("scsi: wd33c93: Mover el puntero SCSI a datos de comando privados") que da como resultado un error en wd33c93_intr(). Esa confirmación agregó la variable scsi_pointer y la inicializó desde hostdata->connected. Sin embargo, durante la selección, hostdata->connected aún no es válido. Solucione esto obteniendo el scsi_pointer actual desde hostdata->selecting.

En el mod de Minecraft "Command Block IDE" hasta la versión 0.4.9 incluida, una autorización faltante (CWE-862) permite a cualquier usuario modificar archivos de "función" utilizados por el juego cuando se instala en un servidor dedicado.

La interfaz API del componente AWV (conferencias de audio, web y video) de Mitel MiCollab hasta la versión 9.8 SP1 FP2 (9.8.1.201) podría permitir que un atacante no autenticado realice una inyección SQL debido a una desinfección insuficiente de la entrada del usuario. Una explotación exitosa podría permitir que un atacante con conocimiento de detalles específicos acceda a información no confidencial sobre el aprovisionamiento de usuarios y ejecute comandos de base de datos SQL arbitrarios.

Una vulnerabilidad en el componente AWV (Audio, Web and Video Conferencing) de Mitel MiCollab hasta la versión 9.8 SP1 FP2 (9.8.1.201) podría permitir que un atacante no autenticado realice un ataque de inyección SQL debido a una desinfección insuficiente de la entrada del usuario. Una explotación exitosa podría permitir que un atacante acceda a información no confidencial de aprovisionamiento de usuarios y ejecute comandos de base de datos SQL arbitrarios.