Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Evite el valor no inicializado en BPF_CORE_READ_BITFIELD [Cambios desde V1: - Use una rama predeterminada en la instrucción switch para inicializar `val'.] GCC advierte que `val' puede usarse sin inicializar en la macro BPF_CRE_READ_BITFIELD, definida en bpf_core_read.h como: [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, campo, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; romper; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \ Este parche agrega una entrada predeterminada en la declaración de cambio que establece `val' en cero para evitar la advertencia, y valores aleatorios que se usarán en caso de que __builtin_preserve_field_info devuelva valores inesperados para BPF_FIELD_BYTE_SIZE. Probado en bpf-next master. Sin regresiones.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: dvb-frontends: tda10048: corrige el estado de desbordamiento de enteros->xtal_hz puede ser de hasta 16 M, por lo que puede desbordar un entero de 32 bits cuando se multiplica por pll_mfactor. Cree una nueva variable de 64 bits para contener los cálculos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mv88e6xxx: Verificación correcta de lista vacía Desde la confirmación a3c53be55c95 ("net: dsa: mv88e6xxx: Soporta múltiples buses MDIO") mv88e6xxx_default_mdio_bus() ha verificado que el valor de retorno de list_first_entry() no es NULL. Esto parece tener como objetivo proteger contra la lista chip->mdios que esté vacía. Sin embargo, no es la comprobación correcta ya que la implementación de list_first_entry no está diseñada para devolver NULL para listas vacías. En su lugar, utilice list_first_entry_or_null() que devuelve NULL si la lista está vacía. Marcado por Smatch. Compilación probada únicamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: reemplace skb_put con skb_put_zero Evite potencialmente reutilizar datos no inicializados

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: uso del valor no inicializado *size al llamar a amdgpu_vce_cs_reloc Inicialice el tamaño antes de llamar a amdgpu_vce_cs_reloc, como en el caso 0x03000001. V2: Para mejorar realmente el manejo, necesitaríamos tener un valor separado de 0xffffffff. (Christian)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: orangefs: corrige el acceso fsid fuera de los límites Arnd Bergmann envió un parche a fsdevel, dice: "orangefs_statfs() copia dos campos consecutivos del superbloque en la estructura statfs, lo que activa una advertencia de los ayudantes de fortificación de cuerdas" Jan Kara sugirió una forma alternativa de hacer el parche para hacerlo más legible. Ejecuté ambas ideas en xfstests y ambas parecen estar bien. Este parche se basa en la sugerencia de Jan Kara.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/drivers/mediatek/lvts_thermal: Verifique NULL ptr en lvts_data Verifique que lvts_data no sea NULL antes de usarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: agregue protección runtime_pm externa a xe_live_ktest@xe_dma_buf. Cualquier kunit que acceda a la memoria debe obtener sus propias referencias externas runtime_pm ya que no usan las entradas API del controlador estándar. En especial este dma_buf del mismo controlador. Encontrado por CI previo a la fusión al agregar llamadas WARN para llamadores internos desprotegidos: <6> [318.639739] # xe_dma_buf_kunit: ejecutando xe_test_dmabuf_import_same_driver <4> [318.639957] ------------[ cortar aquí ]-- ---------- <4> [318.639967] xe 0000:4d:00.0: Falta protección PM de tiempo de ejecución externo <4> [318.640049] ADVERTENCIA: CPU: 117 PID: 3832 en drivers/gpu/drm/xe /xe_pm.c:533 xe_pm_runtime_get_noresume+0x48/0x60 [xe]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs: no advierta de manera engañosa durante las operaciones de descongelación. Es posible que el dispositivo de bloque se haya congelado antes de que un sistema de archivos lo reclamara. Al mismo tiempo, otro proceso podría intentar montar ese dispositivo de bloque congelado y ha reclamado temporalmente el dispositivo de bloque para ese propósito, lo que provoca que un fs_bdev_thaw() concurrente termine aquí. El montador ya está a punto de cancelar el montaje porque todavía vio un bdev->bd_fsfreeze_count elevado, por lo que get_bdev_super() devolverá NULL en ese caso. Por ejemplo, P1 llama a dm_suspend(), que llama a bdev_freeze() antes de que el sistema de archivos haya reclamado el dispositivo de bloque. Esto lleva bdev->bd_fsfreeze_count a 1 y no se requiere ninguna llamada a fs_bdev_freeze(). Ahora P2 intenta montar ese dispositivo de bloque congelado. Lo reclama y comprueba bdev->bd_fsfreeze_count. Al estar elevado se aborta el montaje. Mientras tanto, P3 llamó a dm_resume(). P3 ve que el dispositivo de bloque ya está reclamado por un sistema de archivos y llama a fs_bdev_thaw(). P3 toma una referencia pasiva y se da cuenta de que el sistema de archivos aún no está listo. P3 se pone en modo de suspensión para esperar a que el sistema de archivos esté listo. P2 ahora coloca la última referencia activa al sistema de archivos y lo marca como moribundo. P3 se despierta, ve que el sistema de archivos está muriendo y get_bdev_super() falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: txgbe: elimina la solicitud irq separada para MSI e INTx Cuando se usan interrupciones MSI o INTx, request_irq() para pdev->irq entrará en conflicto con request_threaded_irq() para txgbe->misc .irq, para provocar un fallo del sistema. Por lo tanto, elimine txgbe_request_irq() para el caso MSI/INTx y cambie el nombre de txgbe_request_msix_irqs() ya que solo solicita irqs en cola. Agregue wx->misc_irq_domain para determinar si el controlador crea un dominio IRQ y solicita por subprocesos las IRQ.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: marcar el parámetro bpf_dummy_struct_ops.test_1 como anulable Caso de prueba dummy_st_ops/dummy_init_ret_value pasa NULL como primer parámetro de la función test_1(). Marque este parámetro como anulable para que el verificador sea consciente de tal posibilidad. De lo contrario, NULL verifica el código test_1(): SEC("struct_ops/test_1") int BPF_PROG(test_1, struct bpf_dummy_ops_state *state) { if (!state) return...; ... estado de acceso ... } El verificador podría eliminarlo, lo que provocaría la desreferencia del puntero NULL bajo ciertas condiciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/core: implementar un límite en la lista de recepción de UMAD El comportamiento existente de ib_umad, que mantiene los paquetes MAD recibidos en una lista ilimitada, plantea un riesgo de crecimiento incontrolado. A medida que las aplicaciones del espacio de usuario extraen paquetes de esta lista, es posible que la tasa de extracción no coincida con la tasa de paquetes entrantes, lo que puede provocar un posible desbordamiento de la lista. Para solucionar esto, introducimos un límite al tamaño de la lista. Después de considerar escenarios típicos, como el procesamiento OpenSM, que puede manejar aproximadamente 100 000 paquetes por segundo, y el tiempo de espera de reintento de 1 segundo para la mayoría de los paquetes, establecemos el límite de tamaño de la lista en 200 000. Los paquetes recibidos más allá de este límite se descartan, suponiendo que probablemente se agote el tiempo de espera cuando sean manejados por el espacio de usuario. En particular, los paquetes en cola en la lista de recepción debido a motivos como el tiempo de espera de envío se conservan incluso cuando la lista está llena.