Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: class: Invalidación de punteros de dispositivos USB al cancelar el registro del socio. Para evitar el uso de punteros de dispositivos USB no válidos tras la desconexión de un socio de tipo C, este parche borra los punteros al cancelar el registro del socio. Esto garantiza un estado limpio para futuras conexiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pds_core: Prevenir posible condición de desbordamiento/atascamiento de adminq El adminq de pds_core está protegido por adminq_lock, que impide que se le envíe más de 1 comando a la vez. Esto hace que los controladores del cliente no puedan enviar comandos adminq simultáneamente. Sin embargo, las finalizaciones ocurren en un contexto diferente, lo que significa que se pueden enviar múltiples comandos adminq secuencialmente y todos esperando a ser completados. En el lado del FW, la cola de solicitudes adminq de respaldo solo tiene 16 entradas y falta el mecanismo de reintento o la prevención de desbordamiento/atascamiento. Esto puede provocar que adminq se atasque, por lo que el FW ya no procesa los comandos y ya no envía las finalizaciones. Como solución inicial, evite que haya más de 16 comandos adminq pendientes para que no haya forma de provocar que adminq se atasque. Esto funciona porque la cola de solicitudes adminq de respaldo nunca tendrá más de 16 comandos adminq pendientes, por lo que nunca se desbordará. Esto se hace reduciendo la profundidad de adminq a 16.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: corrige un par de ejecucións en el manejo de MNT_TREE_BENEATH por do_move_mount() Normalmente do_lock_mount(path, _) está bloqueando un punto de montaje fijado por *path y en el momento en que la coincidencia de unlock_mount() desbloquea esa ubicación, todavía está fijado por la misma cosa. Desafortunadamente, para el caso 'debajo' ya no es tan simple: el objeto que se bloquea no es el que *path apunta. Es el punto de montaje de path->mnt. El problema es que, sin un bloqueo suficiente, ->mnt_parent puede cambiar debajo de nosotros y ninguno de los bloqueos se mantiene en ese punto. Las reglas son * mount_lock estabiliza m->mnt_parent para cualquier montaje m. * namespace_sem estabiliza m->mnt_parent, siempre que m esté montado. * si se cumple alguna de las anteriores y refcount de m es positivo, se nos garantiza lo mismo para refcount de m->mnt_parent. namespace_sem se anida dentro de inode_lock(), por lo que do_lock_mount() debe tomar inode_lock() antes de obtener namespace_sem. Vuelve a comprobar que path->mnt siga montado en el mismo lugar después de obtener namespace_sem y se encarga de fijar el dentry. Esto es necesario, ya que, de lo contrario, podríamos terminar con una ejecución de mount --move (o umount) mientras obteníamos bloqueos; en ese caso, el dentry dejaría de ser un punto de montaje y podría haber sido expulsado por presión de memoria junto con su inodo, algo que no se desea al obtener el bloqueo de ese inodo. Sin embargo, fijar un dentry no es suficiente; el montaje correspondiente también está fijado solo por el hecho de que path->mnt está montado sobre él y, en ese momento, no tenemos ningún bloqueo. Por lo tanto, el mismo tipo de ejecución podría terminar con todas las referencias a ese montaje eliminadas justo cuando estamos a punto de entrar en inode_lock(). Si esto ocurre, el sistema de archivos se apaga mientras mantenemos una referencia dentry; los resultados no son muy alentadores. Necesitamos obtener dentry y mount simultáneamente; esto hace que inode_lock() sea seguro *y* evita el problema de que el sistema de archivos se apague bajo nuestra supervisión. Después de obtener namespace_sem, verificamos que path->mnt siga montado (lo que estabiliza su ->mnt_parent) y comprobamos que siga montado en el mismo lugar. Desde ese punto hasta la ejecución correspondiente de namespace_unlock(), tenemos la garantía de que el par mount/dentry que obtuvimos también está fijado al ser el punto de montaje de path->mnt, por lo que podemos eliminar discretamente tanto la referencia dentry (como hace el código actual) como la de mnt; esto es correcto en namespace_sem, ya que no eliminamos las referencias finales. Esto resuelve el problema en do_lock_mount(); unlock_mount() también tiene uno, ya que se garantiza que dentry permanecerá fijado solo hasta la ejecución de namespace_unlock(). Esto es fácil de solucionar: solo hay que hacer inode_unlock() antes, mientras todavía está fijado por mp->m_dentry.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: leds: fix memory leakage Una prueba de reinicio de red en un enrutador provocó una condición de falta de memoria, que se rastreó hasta una fuga de memoria en el código de activación del LED PHY. La causa raíz es el uso indebido de la API devm. La función de registro (phy_led_triggers_register) se llama desde phy_attach_direct, no desde phy_probe, y la función de anulación del registro (phy_led_triggers_unregister) se llama desde phy_detach, no desde phy_remove. Esto significa que las funciones de registro y anulación del registro se pueden llamar varias veces para el mismo dispositivo PHY, pero la memoria asignada por devm no se libera hasta que se desvincula el controlador. Esto también evita que kmemleak detecte la fuga, ya que la API devm almacena internamente el puntero asignado. Solucione esto reemplazando devm_kzalloc/devm_kcalloc con kzalloc/kcalloc estándar y agregue las llamadas kfree correspondientes en la ruta de anulación de registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcm80211: fmac: Añadir gestión de errores para brcmf_usb_dl_writeimage() La función brcmf_usb_dl_writeimage() llama a la función brcmf_usb_dl_cmd() pero no comprueba su valor de retorno. 'state.state' y 'state.bytes' no se inicializan si la función brcmf_usb_dl_cmd() falla. Es peligroso utilizar variables no inicializadas en las condiciones. Añadir gestión de errores para brcmf_usb_dl_cmd() para saltar a la ruta de gestión de errores si brcmf_usb_dl_cmd() falla y 'state.state' y 'state.bytes' no se inicializan. Mejorar el mensaje de error para informar de errores más detallados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: Se corrige el doble fallo de SIGFPE Camm notó que en parisc una excepción SIGFPE bloqueará una aplicación con un segundo SIGFPE en el manejador de señales. Dave lo analizó y sucede porque glibc usa un almacén de punto flotante de doble palabra para actualizar atómicamente los descriptores de función. Como resultado del enlace diferido, llegamos a un almacén de punto flotante en fpe_func casi inmediatamente. Cuando se establece el bit T, se produce una trampa de excepción de asistencia cuando el coprocesador encuentra *cualquier* instrucción de punto flotante excepto un almacén doble del registro %fr0. Este último cancela todas las trampas pendientes. Arreglemos esto borrando el bit Trap (T) en el registro de estado FP antes de regresar al manejador de señales en el espacio de usuario. El problema se puede reproducir con este programa de prueba: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("Señal GOT %d con código si %ld\n", sig, i->código si); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Excepción de punto flotante root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 variables */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ eliminado por SIGFPE +++ Excepción de punto flotante

Esta vulnerabilidad PrivEsc (escalada de privilegios) de alta gravedad se introdujo en las versiones: 9.12.0, 10.3.0, 10.4.0 y 10.5.0 de Jira Core Data Center y Server 5.12.0, 10.3.0, 10.4.0 y 10.5.0 de Jira Service Management Data Center y Server Esta vulnerabilidad PrivEsc (escalada de privilegios), con un puntaje CVSS de 7.2, permite a un atacante realizar acciones como un usuario con mayores privilegios. Atlassian recomienda que los clientes de Jira Core Data Center and Server y Jira Service Management Data Center and Server actualicen a la última versión. Si no pueden hacerlo, actualicen su instancia a una de las versiones fijas compatibles especificadas: Jira Core Data Center and Server 9.12: Actualizar a una versión posterior o igual a la 9.12.20 Jira Service Management Data Center and Server 5.12: Actualizar a una versión posterior o igual a la 5.12.20 Jira Core Data Center 10.3: Actualizar a una versión posterior o igual a la 10.3.5 Jira Service Management Data Center 10.3: Actualizar a una versión posterior o igual a la 10.3.5 Jira Core Data Center 10.4: Actualizar a una versión posterior o igual a la 10.6.0 Jira Service Management Data Center 10.4: Actualizar a una versión posterior o igual a la 10.6.0 Jira Core Data Center 10.5: Actualizar a una versión posterior o igual a la 10.5.1 Jira Service Management Data Center 10.5: Actualice a una versión superior o igual a la 10.5.1. Consulte las notas de la versión. Puede descargar la última versión de Jira Core Data Center y Jira Service Management Data Center desde el centro de descargas. Esta vulnerabilidad se reportó a través de nuestro programa interno de Atlassian.

El D-link DI-8100 16.07.26A1 es vulnerable a la inyección de comandos. Un atacante puede explotar esta vulnerabilidad manipulando solicitudes HTTP específicas, activando la falla de ejecución de comandos y obteniendo acceso de shell con privilegios máximos al sistema de firmware.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corrección de fuga de recursos en la ruta de error blk_register_queue(). Si el registro de una cola falla después de que blk_mq_sysfs_register() se ejecute correctamente, pero la función detecta un error posteriormente, es necesario limpiar los recursos blk_mq_sysfs. Agregue la llamada blk_mq_sysfs_unregister() faltante en la ruta de error para limpiar correctamente estos recursos y evitar una fuga de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: smartpqi: Usar is_kdump_kernel() para comprobar kdump. El controlador smartpqi comprueba la variable reset_devices para determinar si es necesario realizar ajustes especiales para kdump. Esto provoca que, tras un reinicio normal de kexec, algunos parámetros del controlador, como max_transfer_size, sean mucho más bajos de lo habitual. Es más, las pruebas de reinicio de kexec han revelado corrupción de memoria causada por la escritura del registro del controlador en la memoria del sistema después de un kexec. Para solucionar esto, pruebe is_kdump_kernel() en lugar de reset_devices cuando corresponda.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: wl1251: se corrige una fuga de memoria en wl1251_tx_work. El skb desencolado de tx_queue se pierde cuando wl1251_ps_elp_wakeup falla con un error -ETIMEDOUT. Para solucionarlo, vuelva a encolar el skb en tx_queue.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: módulo: Corrección de acceso de reubicación fuera de los límites. El código actual permite que rel[j] acceda a un elemento después del final de la sección de reubicación. Simplificar a num_relocations, que equivale a la expresión de tamaño existente.