Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: ocelot: arregla el bloqueo del sistema en interrupciones basadas en niveles La implementación actual solo llama a chained_irq_enter() y chained_irq_exit() si detecta interrupciones pendientes. ``` for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` Sin embargo, en el caso de que el pin GPIO esté configurado en modo de nivel y el controlador principal esté configurado en modo de borde, el hardware puede reducir la interrupción GPIO. Como resultado, si la interrupción es lo suficientemente corta, la interrupción principal sigue pendiente mientras se borra la interrupción GPIO; chained_irq_enter() nunca se llama y el sistema se cuelga al intentar dar servicio a la interrupción principal. Mover chained_irq_enter() y chained_irq_exit() fuera del bucle for garantiza que se llamen incluso cuando el hardware reduce la interrupción GPIO. El código similar con las funciones chained_irq_enter() / chained_irq_exit() que envuelven el bucle de verificación de interrupciones se puede encontrar en muchos otros controladores: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: veml6030: fix IIO device retrieval from built-in device El puntero dev que se recibe como argumento en la función in_illuminance_period_available_show hace referencia al dispositivo integrado en el dispositivo IIO, no en el cliente i2c. Se debe utilizar dev_to_iio_dev() para acceder a los datos correctos. La implementación actual genera un error de segmentación en cada intento de leer el atributo porque indio_dev obtiene una asignación NULL. Este error ha estado presente desde la primera aparición del controlador, aparentemente desde la última versión (V6) antes de aplicarse. Hasta entonces se utilizaba un atributo constante y es posible que no se hayan vuelto a probar las últimas modificaciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/swapfile: omitir páginas HugeTLB para unuse_vma Obtuve un error pud incorrecto y perdí un HugeTLB de 1 GB al llamar a swapoff. El problema se puede reproducir mediante los siguientes pasos: 1. Asignar un HugeTLB anónimo de 1 GB y otra memoria anónima. 2. Intercambiar la memoria anónima anterior. 3. Ejecutar swapoff y obtendremos un error pud incorrecto en el mensaje del kernel: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) Podemos decir que pud_clear_bad es llamado por pud_none_or_clear_bad en unuse_pud_range() por ftrace. Y por lo tanto, las páginas HugeTLB nunca se liberarán porque las perdimos de la tabla de páginas. Podemos omitir las páginas HugeTLB para unuse_vma para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: maple_tree: corregir la corrupción del árbol en el almacén de expansión Serie de parches "maple_tree: corregir la corrupción del árbol en el almacén de expansión", v3. Ha habido un error de corrupción del árbol de maple desagradable pero sutil que parece haber existido desde el inicio del algoritmo. Este error parece mucho más probable que ocurra desde el commit f8d112a4e657 ("mm/mmap: evitar poner a cero el árbol vma en mmap_region()"), que es el punto en el que comenzaron a enviarse informes sobre este error. Nos enteramos definitivamente del error gracias a los amables esfuerzos de Bert Karwatzki, quien me ayudó enormemente a poder rastrearlo e identificar la causa. El error surge cuando se intenta realizar un almacenamiento de expansión en dos nodos de hoja, donde el nodo de hoja derecho es el hijo más a la derecha del padre compartido, y el almacenamiento consume por completo el nodo de modo derecho. Esto da como resultado que mas_wr_spanning_store() duplique por error las entradas nuevas y existentes en el pivote máximo dentro del rango, y por lo tanto la corrupción del árbol de maple. El parche de corrección corrige esto detectando este escenario y no permitiendo la copia duplicada errónea. El mensaje de confirmación del parche de corrección detalla en gran medida cómo ocurre esto. Esta serie también incluye una prueba que reproduce el problema de manera confiable y afirma que la corrección funciona correctamente. Bert ha probado amablemente la corrección y confirmó que resolvió sus problemas. Además, Mikhail Gavrilov informó amablemente lo que parece ser exactamente el mismo error, que esta corrección también debería resolver. Este parche (de 2): Ha habido un error sutil presente en la implementación del árbol de maple desde su inicio. Esto surge de cómo se realizan los almacenamientos: cuando se produce un almacenamiento, sobrescribirá los rangos superpuestos y ajustará el árbol según sea necesario para adaptarse a esto. Un rango siempre puede abarcar en última instancia dos nodos de hoja. En este caso, recorremos los dos nodos de hoja, determinamos qué elementos no se sobrescriben a la izquierda y a la derecha del inicio y el final de los rangos respectivamente y luego reequilibramos el árbol para que contenga estas entradas y la recién insertada. Este tipo de almacenamiento se denomina "almacén de expansión" y se implementa mediante mas_wr_spanning_store(). Para llegar a esta etapa, mas_store_gfp() invoca a mas_wr_preallocate(), mas_wr_store_type() y mas_wr_walk() a su vez para recorrer el árbol y actualizar el objeto (mas) para atravesar la ubicación donde se debe realizar la escritura, determinando su tipo de almacenamiento. Cuando se requiere un almacenamiento de expansión, esta función devuelve falso y se detiene en el nodo principal que contiene el rango de destino, y mas_wr_store_type() marca mas->store_type como wr_spanning_store para denotar este hecho. Cuando vamos a realizar el almacenamiento en mas_wr_spanning_store(), primero determinamos los elementos DESPUÉS del FINAL del rango que deseamos almacenar (es decir, a la derecha de la entrada que se insertará); lo hacemos caminando hasta el SIGUIENTE pivote en el árbol (es decir, r_mas.last + 1), comenzando en el nodo que acabamos de determinar que contiene el rango sobre el que pretendemos escribir. Luego dirigimos nuestra atención a las entradas a la izquierda de la entrada que estamos insertando, cuyo estado está representado por l_mas, y las copiamos en un "nodo grande", que es un nodo especial que contiene suficientes ranuras para contener los datos de dos nodos hoja. Luego copiamos la entrada que deseamos almacenar inmediatamente después de esto; la copia y la inserción de la nueva entrada se realiza mediante mas_store_b_node(). Después de esto, copiamos los elementos a la derecha del final del rango que estamos insertando, si no hemos excedido la longitud del nodo (es decir, r_mas.offset <= r_mas.end). ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/radeon: Fix encoder->possible_clones Incluir el codificador en sí mismo en su máscara de bits possible_clones. En el pasado, nada validaba que los controladores estuvieran completando possible_clones correctamente, pero eso cambió en el commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Parece que Radeon nunca recibió la nota y todavía no sigue las reglas correctamente al 100%. Esto genera algunas advertencias durante la inicialización del controlador: Possible_clones falsos: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) ADVERTENCIA: CPU: 0 PID: 170 en drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (seleccionado de el commit 3b6e7d40649c0d75572039aff9d0911864c689db)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: propagar errores de lectura de directorio desde nilfs_find_entry() Syzbot informó que se produce un bloqueo de tarea en vcs_open() durante una prueba de fuzzing para nilfs2. La causa raíz de este problema es que en nilfs_find_entry(), que busca entradas de directorio, ignora los errores cuando falla la carga de una página/folio de directorio a través de nilfs_get_folio(). Si las imágenes del sistema de archivos están dañadas, y el i_size del inodo del directorio es grande, y la página/folio del directorio se lee correctamente pero falla la comprobación de cordura, por ejemplo, cuando está llena de ceros, nilfs_check_folio() puede seguir arrojando mensajes de error en ráfagas. Solucione este problema propagando el error a los llamadores cuando falla la carga de una página/folio en nilfs_find_entry(). La interfaz actual de nilfs_find_entry() y sus llamadores está desactualizada y no puede propagar códigos de error como -EIO y -ENOMEM devueltos a través de nilfs_find_entry(), así que arréglenlo juntos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: firewire-lib: Evitar la división por cero en apply_constraint_to_size() La variable de paso se inicializa a cero. Se cambia en el bucle, pero si no se cambia, permanecerá en cero. Agregue una comprobación de variable antes de la división. El comportamiento observado fue introducido por el commit 826b5de90c0b ("ALSA: firewire-lib: corregir regla PCM insuficiente para tamaño de período/búfer"), y es difícil demostrar que alguno de los parámetros de intervalo satisfará la condición snd_interval_test() con datos de la tabla amdtp_rate_table[]. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: se corrige una advertencia de UBSAN en DML2.1 Al programar una tubería fantasma, dado que cursor_width se establece explícitamente en 0, esto hace que la lógica de cálculo active un desbordamiento para un int sin signo que activa la comprobación UBSAN del kernel como se muestra a continuación: [ 40.962845] UBSAN: desplazamiento fuera de los límites en /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] El exponente de desplazamiento 4294967170 es demasiado grande para el tipo de 32 bits 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Contaminado: GW OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Nombre del hardware: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Seguimiento de llamadas: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? recurso_agregar_dpp_tuberías_para_composición_de_planos+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Solucione esto agregando una protección para verificar el ancho del cursor antes de activar el cálculo del tamaño.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: loongson3: Use raw_smp_processor_id() en do_service_request() Use raw_smp_processor_id() en lugar de smp_processor_id() simple en do_service_request(), de lo contrario podemos obtener algunos errores con el controlador habilitado: ERROR: uso de smp_processor_id() en código preemptible [00000000]: (udev-worker)/208 el que llama es loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: imx: eliminar CLK_SET_PARENT_GATE para mux DRAM para i.MX7D Para el reloj mux relacionado con DRAM i.MX7D, el cambio de fuente de reloj SÓLO debe realizarse en código asm de bajo nivel sin acceder a DRAM, y luego llamar a la API clk para sincronizar el estado del reloj de HW con el árbol clk, nunca debe tocar el cambio de fuente de reloj real a través de la API clk, por lo que el indicador CLK_SET_PARENT_GATE NO debe agregarse, de lo contrario, el reloj padre de DRAM se deshabilitará cuando DRAM esté activo y el sistema se colgará.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: se corrige la pérdida de memoria en ice_init_tx_topology() Se corrige la pérdida del blob de FW (paquete DDP). Se hace que ice_cfg_tx_topo() sea constante y correcto, de modo que ice_init_tx_topology() pueda evitar copiar todo el blob de FW. Se copia solo la sección de topología y solo cuando es necesario. Se reutiliza el búfer asignado para la lectura de la topología actual. Esto fue encontrado por kmemleak, con el siguiente rastro para cada PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Parámetros de conversión de ice_cfg_tx_topo() @buf. Esto se aplica en cascada a algunas funciones más.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: k3-r5: Se corrige el manejo de errores cuando falla el encendido. Con solo salir del sistema, el controlador estaba violando su regla y suposiciones internas de que se deben inicializar ambos rproc o ninguno. Por ejemplo, esto podría provocar que el primer núcleo esté disponible pero no el segundo, lo que provocaría fallas en su apagado más adelante al intentar desreferenciar esa segunda instancia.