Vulnerabilidades

Razón rechazado: no se usa

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: objtool, spi: amd: Se corrige el acceso a la pila fuera de los límites en amd_set_spi_freq(). Si speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() itera sobre toda la matriz amd_spi_freq sin interrumpir la ejecución antes de tiempo, lo que provoca que 'i' supere los límites de la matriz. Para solucionar esto, se detiene el bucle al llegar a la última entrada, de modo que el valor bajo de speed_hz se limite a AMD_SPI_MIN_HZ. Se corrige la siguiente advertencia con un kernel UBSAN: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falla a la siguiente función amd_spi_set_opcode().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: gpib: Fix cb7210 pcmcia Oops. La estructura pcmcia_driver seguía usando únicamente la inicialización anterior de .name en el campo drv. Esto provocaba un puntero nulo deref Oops en strcmp llamado desde pcmcia_register_driver. Inicialice el campo name de la estructura pcmcia_driver.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: objtool, nvmet: Se corrige el acceso a la pila fuera de los límites en nvmet_ctrl_state_show(). La matriz csts_state_names[] solo tiene seis entradas dispersas, pero el código de iteración en nvmet_ctrl_state_show() itera siete, lo que resulta en una posible lectura de la pila fuera de los límites. Se soluciona. Se corrige la siguiente advertencia con un kernel UBSAN: vmlinux.o: advertencia: objtool: .text.nvmet_ctrl_state_show: final inesperado de sección.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: Agregar comprobación de los límites de matriz en veml6075_read_int_time_ms La matriz contiene solo 5 elementos, pero el índice calculado por veml6075_read_int_time_index puede variar de 0 a 7, lo que podría provocar un acceso fuera de los límites. La comprobación evita este problema. Coverity Issue CID 1574309: (#1 de 1): Lectura fuera de los límites (OVERRUN) overrun-local: Desbordamiento de la matriz veml6075_it_ms de 5 elementos de 4 bytes en el índice de elemento 7 (desplazamiento de byte 31) utilizando el índice int_index (que evalúa a 7) Esto es endurecimiento contra hardware potencialmente dañado. Es bueno tenerlo, pero no es necesario retroportarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mce: usar is_copy_from_user() para determinar el contexto de copia del usuario. Serie de parches "mm/hwpoison: Corregir regresiones en la gestión de fallos de memoria", v4. ## 1. ¿Qué intento hacer?: Este conjunto de parches resuelve dos regresiones críticas relacionadas con la gestión de fallos de memoria que han aparecido en el kernel original desde la versión 5.17, en comparación con la 5.10 LTS. - caso de copyin: se encontró un error en la página de usuario mientras el kernel copiaba desde el espacio de usuario. - caso de instr: se encontró un error al obtener instrucciones en el espacio de usuario. ## 2. ¿Cuál es el resultado esperado y por qué? - Para el caso de copyin: el kernel puede recuperarse del error encontrado donde el kernel ejecuta get_user() o copy_from_user() si en esos lugares se obtiene un error y el kernel devuelve -EFAULT al proceso en lugar de bloquearse. Más específicamente, el controlador de MCE comprueba el tipo de controlador de corrección para decidir si se puede recuperar un #MC en el kernel. Cuando se encuentra EX_TYPE_UACCESS, el PC salta al código de recuperación especificado en _ASM_EXTABLE_FAULT() y devuelve un -EFAULT al espacio de usuario. - En el caso de instr: Si se encuentra un error durante la obtención de instrucciones en el espacio de usuario, es posible una recuperación completa. El proceso de usuario toma #PF, Linux asigna una nueva página y la completa leyendo del almacenamiento. ## 3. Qué sucede realmente y por qué - En el caso de copyin: Pánico del kernel desde la v5.17. El commit 4c132d1d844a ("x86/futex: Eliminar el uso de .fixup") introdujo un nuevo tipo de corrección extable, EX_TYPE_EFAULT_REG, y parches posteriores actualizaron el tipo de corrección extable para operaciones de copia desde el usuario, cambiándolo de EX_TYPE_UACCESS a EX_TYPE_EFAULT_REG. Esto interrumpe la gestión previo de EX_TYPE_UACCESS cuando se encuentra error en get_user() o copy_from_user(). - Para el caso instr: el proceso del usuario es eliminado por una señal SIGBUS debido a la ejecución #CMCI y #MCE Cuando se consume un error de memoria sin corregir, hay una ejecución entre el CMCI del controlador de memoria que informa un error sin corregir con una firma UCNA y el informe del núcleo y la comprobación de la máquina con firma SRAR cuando los datos están a punto de consumirse. ### Antecedentes: por qué los errores *UN*corregidos están vinculados a *C*MCI en la plataforma Intel [1] Antes de Icelake, los controladores de memoria informaban de eventos de depuración de patrullaje que detectaban un error sin corregir no visto previamente en la memoria mediante la señalización de una comprobación de la máquina de difusión con una firma SRAO (Acción recuperable de software opcional) en el banco de comprobación de la máquina. Esto era excesivo porque no es un problema urgente que ningún núcleo esté a punto de consumir esos datos erróneos. También se ha descubierto que varias UCE SRAO pueden causar interrupciones MCE anidadas y, finalmente, convertirse en una IERR. Por lo tanto, Intel degrada la firma del banco de verificación de la máquina de la limpieza de patrullaje de SRAO a UCNA (sin corregir, no se requiere acción) y la señal cambia a #CMCI. Para aumentar la confusión, Linux realiza una acción (en uc_decode_notifier()) para intentar desconectar la página a pesar del nombre de la firma UC*NA*. ### Antecedentes: ¿por qué #CMCI y #MCE compiten cuando el veneno consume datos en la plataforma Intel? [1] Tras decidir que CMCI/UCNA es la mejor acción para los errores de limpieza de patrullaje, el controlador de memoria también la utiliza para las lecturas. Sin embargo, el controlador de memoria se ejecuta de forma asíncrona desde el núcleo y no puede distinguir entre una lectura "real" y una lectura especulativa. Por lo tanto, ejecutará CMCI/UCNA si se encuentra un error en cualquier lectura. Por lo tanto: 1) El núcleo es inteligente y cree que ----truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/raid10: esperar la barrera antes de devolver una solicitud de descarte con REQ_NOWAIT. raid10_handle_discard debe esperar la barrera antes de devolver una bio de descarte con REQ_NOWAIT. No es necesario imprimir un seguimiento de llamadas de advertencia si una bio de descarte tiene la bandera REQ_NOWAIT. El ingeniero de calidad suele revisar dmesg e informa de un error si dmesg tiene un seguimiento de llamadas de advertencia/error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: samsung: Corregir el pánico de UBSAN en samsung_clk_init(). Con UBSAN_ARRAY_BOUNDS=y, se produce el pánico indicado debido a la desreferencia de `ctx->clk_data.hws` antes de configurar `ctx->clk_data.num = nr_clks`. Corregir esta vulnerabilidad para corregir el fallo. UBSAN: índice de matriz fuera de los límites: 00000000f2005512 [#1] PREEMPT SMP Rastreo de llamadas: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: corrección de lectura fuera de los límites de slab en ea_get(). Durante la etiqueta "size_check" en ea_get(), el código comprueba si el tamaño de la lista de atributos extendidos (xattr) coincide con ea_size. De lo contrario, registra "ea_get: atributo extendido no válido" y llama a print_hex_dump(). En este caso, EALIST_SIZE(ea_buf->xattr) devuelve 4110417968, que excede INT_MAX (2147483647). A continuación, se fija ea_size: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Aunque clamp_t busca limitar ea_size entre 0 y 4110417968, el límite superior se trata como un entero, lo que provoca un desbordamiento por encima de 2^31 - 1. Esto hace que "size" se repita y se vuelva negativo (-184549328). El "size" se pasa a print_hex_dump() (llamado "len" en print_hex_dump()) como tipo size_t (un tipo sin signo). Este se almacena en una variable llamada "int remaining", que se asigna a "int linelen", que a su vez se pasa a hex_dump_to_buffer(). En print_hex_dump(), el bucle for itera desde 0 hasta len-1, donde len es 18446744073525002176 y llama a hex_dump_to_buffer() en cada iteración: for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize; hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii); ... } La condición de detención esperada (i < len) se rompe efectivamente ya que len está dañado y es muy grande. Esto eventualmente lleva a que "ptr+i" se pase a hex_dump_to_buffer() para acercarse al final de los límites reales de "ptr", eventualmente se realiza un acceso fuera de los límites en hex_dump_to_buffer() en el siguiente bucle for: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... } Para solucionar esto debemos validar "EALIST_SIZE(ea_buf->xattr)" antes de utilizarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: simple-card-utils: No usar __free(device_node) en el commit 419d1918105e de graph_util_parse_dai() ("ASoC: simple-card-utils: usar __free(device_node) para el nodo de dispositivo") usa __free(device_node) para dlc->of_node, pero es necesario mantenerlo mientras se usa el controlador. No usar __free(device_node) en graph_util_parse_dai().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/resctrl: Se corrige la asignación del CLOSID más limpio en plataformas sin monitores. El commit 6eac36bb9eb0 ("x86/resctrl: Asignar el CLOSID más limpio buscando closid_num_dirty_rmid") añadió lógica que hace que resctrl busque el CLOSID con la menor cantidad de líneas de caché sucias al crear un nuevo grupo de control, si así lo solicita el código de la arquitectura. Esto depende de los valores leídos de los contadores llc_occupancy. Esta lógica es aplicable a arquitecturas donde el CLOSID forma parte del identificador de monitorización y, por lo tanto, no permite total libertad para elegir un identificador de monitorización sin usar para un CLOSID determinado. Esta compatibilidad no tuvo en cuenta que algunas plataformas podrían no tener estos contadores. Esto provoca una desreferencia de puntero nulo al crear un nuevo grupo de control, ya que la matriz no fue asignada por dom_data_init(). Como esta función no es necesaria en plataformas que no tienen monitores de ocupación de caché, agregue esto a la verificación que se realiza cuando se asigna un nuevo grupo de control.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: fsl-edma: libera irq correctamente en la ruta de eliminación. Agrega la verificación fsl_edma->txirq/errirq para evitar la siguiente advertencia porque no hay errirq en la plataforma i.MX9. De lo contrario, habrá un volcado de kernel: ADVERTENCIA: CPU: 0 PID: 11 at kernel/irq/devres.c:144 devm_free_irq+0x74/0x80 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u8:0 Not tainted 6.12.0-rc7#18 Hardware name: NXP i.MX93 11X11 EVK board (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devm_free_irq+0x74/0x80 lr : devm_free_irq+0x48/0x80 Call trace: devm_free_irq+0x74/0x80 (P) devm_free_irq+0x48/0x80 (L) fsl_edma_remove+0xc4/0xc8 platform_remove+0x28/0x44 device_remove+0x4c/0x80