Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86: deja de jugar juegos de pila en perfil_pc() La función 'profile_pc()' se utiliza para la creación de perfiles basada en temporizador, lo cual ya no es tan relevante para empezar. , pero también termina haciendo suposiciones basadas en el diseño de la pila que no son necesariamente válidas. Básicamente, el código intenta contabilizar el tiempo invertido en bloqueos de giro para la persona que llama en lugar del bloqueo de giro, y si bien apoyo eso como concepto, no vale la pena la complejidad del código o las advertencias de KASAN cuando de todos modos no se realiza una creación de perfiles seria usando temporizadores en estos días. . Y el código realmente depende del diseño de la pila, lo que solo es cierto en los casos más simples. Perdimos el comentario en algún momento (creo que cuando se unificó el código de 32 y 64 bits), pero solía decir: Supongamos que la función de bloqueo no tiene marco de pila o tiene una copia de eflags de PUSHF. lo que explica por qué simplemente carga ciegamente una o dos palabras directamente desde el puntero de la pila y luego echa un vistazo mínimo a los valores para comprobar si podrían ser eflags o la PC de retorno: Eflags siempre tiene los bits 22 y superiores limpios, a diferencia de las direcciones del kernel, pero Esa suposición básica del diseño de la pila supone que no hay ninguna depuración de bloqueo, etc., que complicaría el código y provocaría un marco de pila. Provoca la infelicidad de KASAN que Syzkaller [1] y otros [2] han informado durante años. Sin ninguna razón práctica real para esto, simplemente elimine el código. Solo por interés histórico, aquí hay algunas confirmaciones de antecedentes relacionadas con este código de 2006: 0cb91a229364 ("i386: La cuenta se bloquea en la persona que llama durante la creación de perfiles para los núcleos !FP") 31679f38d886 ("Simplificar perfil_pc en x86-64") y una unificación de código de 2009: ef4512882dbe ("x86: time_32/64.c unify perfil_pc") pero los conceptos básicos de esto en realidad se remontan a antes del árbol git.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: emux: mejorar la validación de datos del parche ioctl En load_data(), hacer que la validación y la omisión del bloque de información principal coincidan con la de load_guspatch(). En load_guspatch(), agregue la verificación de que la longitud del parche especificado coincida con los datos realmente proporcionados, como ya lo hizo load_data().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: ecdh: poner a cero explícitamente la clave privada la clave privada se sobrescribe con el parámetro clave pasado por la persona que llama (si está presente) o, alternativamente, con una clave privada recién generada. Sin embargo, es posible que la persona que llama proporcione una clave (o la clave recién generada) que sea más corta que la clave anterior. En ese escenario, parte del material clave de la clave anterior no se sobrescribiría. La solución más sencilla es poner primero a cero explícitamente toda la matriz de claves privadas. Tenga en cuenta que este parche cambia ligeramente el comportamiento de esta función: anteriormente, si ecc_gen_privkey fallaba, la antigua clave privada permanecería. Ahora, la private_key siempre se pone a cero. Este comportamiento es coherente con el caso en el que se establece params.key y ecc_is_key_valid falla.

Las versiones de Delphix Engine anteriores a la versión 25.0.0.0 contienen un fallo que resulta en la ejecución remota de código (RCE).

Unafallo en las versiones de Delphix Data Control Tower (DCT) anteriores a la 19.0.0 da como resultado una autenticación rota a través de la funcionalidad de prueba de escala de habilitación de la aplicación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: verifique pat.ops antes de volcar la configuración de PAT. Podemos dejar pat.ops sin configurar cuando se ejecuta en una plataforma nueva o cuando se ejecuta como VF. Si bien lo primero es poco probable, el segundo es un caso de uso válido (futuro) y causará NPD cuando alguien intente volcar la configuración de PAT mediante debugfs. Es mejor marcar el puntero a pat.ops en lugar del gancho .dump específico, ya que siempre tenemos este gancho definido para cada variante de .ops.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: gpio: davinci: valida el número de IRQ obtenidos. El valor de pdata->gpio_unbanked se toma del árbol de dispositivos. En caso de DT roto debido a algún error, este valor puede ser cualquiera. Sin esta validación de valor, puede haber acceso sin chips->irqs a los límites de la matriz en davinci_gpio_probe(). Valide el valor nirq obtenido para que no exceda el número máximo de IRQ por banco. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/dpaa2: evite la asignación explícita de la variable cpumask en la pila. Para el kernel CONFIG_CPUMASK_OFFSTACK=y, no se recomienda la asignación explícita de la variable cpumask en la pila, ya que puede causar un posible desbordamiento de la pila. En su lugar, el código del kernel siempre debe usar las API *cpumask_var para asignar cpumask var de manera neutral en cuanto a configuración, dejando la estrategia de asignación a CONFIG_CPUMASK_OFFSTACK. Utilice las API *cpumask_var para solucionarlo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/iucv: evite la asignación explícita de la variable cpumask en la pila. Para el kernel CONFIG_CPUMASK_OFFSTACK=y, no se recomienda la asignación explícita de la variable cpumask en la pila, ya que puede causar un posible desbordamiento de la pila. En su lugar, el código del kernel siempre debe usar las API *cpumask_var para asignar cpumask var de manera neutral en cuanto a configuración, dejando la estrategia de asignación a CONFIG_CPUMASK_OFFSTACK. Utilice las API *cpumask_var para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftruncate: pasa un desplazamiento firmado La antigua llamada al sistema ftruncate(), que utiliza off_t de 32 bits, pierde una extensión de signo cuando se llama en modo de compatibilidad en arquitecturas de 64 bits. Como resultado, pasar una longitud negativa accidentalmente logra truncar el tamaño del archivo entre 2GiB y 4GiB. Cambiar el tipo de llamada al sistema compat a compat_off_t firmado cambia el comportamiento, por lo que en su lugar devuelve -EINVAL. El punto de entrada nativo, la llamada al sistema truncate() y las variantes correspondientes basadas en loff_t ya son correctas y no sufren este error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: core: elimina el bloqueo del modo otg durante la suspensión/reanudación del dispositivo para evitar un punto muerto Cuando se selecciona config CONFIG_USB_DWC3_DUAL_ROLE y activa el sistema para que entre en estado de suspensión con el siguiente comando: echo mem > /sys/power/state Se producirá un problema de interbloqueo. Ruta de invocación detallada como se muestra a continuación: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <-- 1er dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->bloquear, banderas); <-- 2.º Este problema se expone mediante la confirmación c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") que elimina el código para verificar si dwc->gadget_driver es NULL o no. Hace que se ejecute el siguiente código y se produzca un punto muerto al intentar obtener el bloqueo de giro. De hecho, la causa principal es la confirmación 5265397f9442("usb: dwc3: Eliminar el bloqueo de DWC3 durante la suspensión/reanudación del dispositivo") que olvidó eliminar el bloqueo del modo otg. Por lo tanto, elimine el bloqueo redundante del modo otg durante la suspensión/reanudación del dispositivo.

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: iio:chemical:bme680: Corregir desbordamientos en funciones de compensación(). Hay casos en las funciones de compensación del controlador en los que se pueden producir desbordamientos de variables por operaciones de cambio de bits. Estas implicaciones se discutieron inicialmente aquí [1] y se mencionaron en el mensaje de registro del compromiso 1b3bd8592780 ("iio: químico: agregar soporte para el sensor Bosch BME680"). [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/