Vulnerabilidades

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.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: hisilicon/debugfs: soluciona el problema del proceso uninit de debugfs. Durante el proceso de sonda zip, la falla de debugfs no detiene la sonda. Cuando falla la inicialización de debugfs, saltar a la rama de error también liberará los registros, además de su propia operación de reversión. Como resultado, es posible que se libere repetidamente durante el proceso de uninidad de registros. Por lo tanto, es necesario agregar la verificación nula al proceso regs uninit.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnx2x: corrige múltiples índices de matriz UBSAN fuera de los límites. Corrige las advertencias de UBSAN que ocurren cuando se usa un sistema con 32 núcleos de CPU físicos o más, o cuando el usuario define un número. de colas Ethernet mayores o iguales a FP_SB_MAX_E1x usando el parámetro del módulo num_queues. Actualmente hay una lectura/escritura fuera de los límites que se produce en la matriz "struct stats_query_entry query" presente dentro de la estructura "bnx2x_fw_stats_req" en "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Mirando la definición de la matriz "struct stats_query_entry query": struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX]; FP_SB_MAX_E1x se define como el número máximo de interrupciones de ruta rápida y tiene un valor de 16, mientras que BNX2X_FIRST_QUEUE_QUERY_IDX tiene un valor de 3, lo que significa que la matriz tiene un tamaño total de 19. Dado que los accesos a "struct stats_query_entry query" están compensados por BNX2X_FIRST_QUEUE_QUERY_IDX, eso significa que el número total de colas Ethernet no debe exceder FP_SB_MAX_E1x (16). Sin embargo, una de estas colas está reservada para FCOE y, por lo tanto, el número de colas Ethernet debe establecerse en [FP_SB_MAX_E1x -1] (15) si FCOE está habilitado o [FP_SB_MAX_E1x] (16) si no lo está. Esto también se describe en un comentario en el código fuente en drivers/net/ethernet/broadcom/bnx2x/bnx2x.h justo encima de la definición de macro de FP_SB_MAX_E1x. A continuación se muestra la parte de esta explicación que es importante para este parche /* * El número total de colas L2, vectores MSIX y contextos HW (CID) está * controlado por el número de bloques de estado de ruta rápida admitidos por el * dispositivo (HW /FW). Cada bloque de estado de ruta rápida (FP-SB), también conocido como bloque de estado no predeterminado *, representa un contexto de interrupciones independiente que puede * servir a una cola de red L2 normal. Sin embargo, las colas L2 especiales, como * como la cola FCoE, no requieren un FP-SB y otros componentes como * el CNIC pueden consumir FP-SB, lo que reduce el número de colas L2 posibles * * Si el número máximo de FP-SB disponibles es X, entonces : * a. Si se admite CNIC, consume 1 FP-SB, por lo que el número máximo de * colas L2 regulares es Y=X-1 * b. En el modo MF, el número real de colas L2 es Y= (X-1/MF_factor) * c. Si se admite la cola FCoE L2, el número real de colas L2 * es Y+1 * d. El número de irqs (vectores MSIX) es Y+1 (uno adicional para * interrupciones de ruta lenta) o Y+2 si se admite CNIC (un contexto de interrupción * FP adicional para el CNIC). * e. El número de contexto de HW (recuento de CID) siempre es X o X+1 si se admite la cola FCoE * L2. El cid para la cola FCoE L2 siempre es X. */ Sin embargo, este controlador también admite NIC que usan el controlador E2, que puede manejar más colas debido a que tiene más FP-SB representado por FP_SB_MAX_E2. Al observar las confirmaciones cuando se agregó el soporte E2, originalmente se usaban los parámetros E1x: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). En aquel entonces, FP_SB_MAX_E2 se configuró en 16 al igual que E1x. Sin embargo, el controlador se actualizó posteriormente para aprovechar al máximo el E2 en lugar de limitarlo a las capacidades del E1x. Pero hasta donde sabemos, la "consulta stats_query_entry" de la matriz todavía se limitaba a usar el FP-SB disponible para las tarjetas E1x como parte de una sobreseñal cuando se actualizó el controlador para aprovechar al máximo el E2, y ahora con el Al ser consciente el controlador del mayor tamaño de cola admitido por las NIC E2, se generan las advertencias de UBSAN que se ven en los seguimientos de pila a continuación. Este parche aumenta el tamaño de la matriz "stats_query_entry query" reemplazando FP_SB_MAX_E1x con FP_SB_MAX_E2 para que sea lo suficientemente grande como para manejar ambos tipos de NIC. Seguimientos de pila: UBSAN: ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: corrige una posible fuga al destruir un ctrl durante el establecimiento de qp En nvmet_sq_destroy capturamos sq->ctrl temprano y si no es NULL sabemos que se asignó un ctrl (en el controlador de solicitudes de conexión de administrador) y necesitamos liberar los AER pendientes, borrar ctrl->sqs y sq->ctrl (principalmente para nvme-loop) y eliminar la referencia final en ctrl. Sin embargo, es posible una pequeña ventana donde se inicia nvmet_sq_destroy (como resultado de que el cliente se rinde y se desconecta) al mismo tiempo que el cmd de conexión del administrador de nvme (que puede estar en una etapa inicial). Pero *antes* de kill_and_confirm de sq->ref (es decir, la conexión del administrador logró obtener una referencia en vivo de sq). En este caso, se asignó sq->ctrl sin embargo después de ser capturado en una variable local en nvmet_sq_destroy. Esto evitó la caída de la referencia final en Ctrl. Resuelva esto volviendo a capturar sq->ctrl después de que se hayan completado todas las solicitudes en curso, donde con seguridad la referencia sq->ctrl es definitiva, y avance en función de eso. Este problema se observó en un entorno con muchos hosts que conectaban múltiples controles simultáneamente, lo que creaba un retraso en la asignación de un control que conducía a esta ventana de ejecución.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: pnx: corrige la advertencia de posible interbloqueo de la llamada del_timer_sync() en isr Cuando se llama a del_timer_sync() en un contexto de interrupción, genera una advertencia debido a un posible interbloqueo. El temporizador se usa solo para salir de wait_for_completion() después de un tiempo de espera, por lo que reemplazar la llamada con wait_for_completion_timeout() permite eliminar por completo el temporizador problemático y sus funciones relacionadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp_metrics: validar la longitud de la dirección de origen. No veo nada comprobando que TCP_METRICS_ATTR_SADDR_IPV4 tenga al menos 4 bytes de longitud y la política no tiene ninguna entrada para este atributo (tampoco lo hace para IPv6 pero v6 se valida manualmente).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bluetooth/hci: no permitir configuración de identificador mayor que HCI_CONN_HANDLE_MAX Advertencia de activación de Syzbot en hci_conn_del() causada por la liberación del identificador que no se asignó mediante el asignador de ida. Esto se debe a un identificador mayor que HCI_CONN_HANDLE_MAX pasado por hci_le_big_sync_establecido_evt(), lo que hace que el código piense que es una conexión no configurada. Agregue la misma verificación para el límite superior del controlador que en hci_conn_set_handle() para evitar advertencias.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: ignorar valores de identificador demasiado grandes en BIG hci_le_big_sync_establecido_evt es necesario para filtrar los casos en los que el valor de identificador pertenece al rango de identificación de ida; de lo contrario, ida se publicará erróneamente en hci_conn_cleanup.