Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: cacheinfo: Se corrige la asignación incorrecta de un valor de error con signo a unsigned fw_level. Aunque acpi_find_last_cache_level() siempre devolvía un valor con signo y el documento indica que devolverá cualquier error causado por la falta de una tabla PPTT, nunca antes devolvía valores negativos. Sin embargo, el commit 0c80f9e165f8 ("ACPI: PPTT: Dejar la tabla asignada para el uso en tiempo de ejecución") la modificó devolviendo -ENOENT si no se encontraba PPTT. El valor devuelto por acpi_find_last_cache_level() se asigna entonces a unsigned fw_level. Esto provocará que el número de hojas de caché se calcule incorrectamente como un valor enorme, lo que provocará la siguiente advertencia de __alloc_pages, ya que el orden sería mayor que MAX_ORDER debido a un valor incorrecto y enorme de hojas de caché. ADVERTENCIA: CPU: 0 PID: 1 en mm/page_alloc.c:5407 __alloc_pages+0x74/0x314 | Módulos vinculados: | CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.19.0-10393-g7c2a8d3ac4c0 #73 | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __alloc_pages+0x74/0x314 | lr : alloc_pages+0xe8/0x318 | Rastreo de llamadas: | __alloc_pages+0x74/0x314 | alloc_pages+0xe8/0x318 | kmalloc_order_trace+0x68/0x1dc | Corrija el mismo problema cambiando fw_level para que sea un entero con signo y devuelva el error de init_cache_level() de manera temprana en caso de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: agregar interfaces ->fini_xxxx faltantes para algunos ASIC SMU13. Sin estas, se puede inducir una posible pérdida de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: agregar la interfaz ->fini_microcode faltante para Sienna Cichlid para evitar cualquier posible pérdida de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Hacer mark_chain_precision para ARG_CONST_ALLOC_SIZE_OR_ZERO Los marcadores de precisión deben propagarse siempre que tengamos un argumento de estilo ARG_CONST_*, ya que el verificador no puede considerar que los escalares imprecisos sean equivalentes para los fines de la comprobación states_equal cuando dichos argumentos refinan el valor de retorno (en este caso, establecer mem_size para PTR_TO_MEM). El mem_size resultante para el R0 se deriva del valor constante, y si el verificador poda incorrectamente los estados considerándolos equivalentes donde existen dichos argumentos (al ver que ambos registros tienen reg->precise como falso en regsafe), podemos terminar con programas no válidos que pasan el verificador que pueden hacer acceso más allá de lo que debería haber sido el mem_size correcto en ese estado explorado. Para mostrar un ejemplo concreto del problema: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: si r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: si w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: llamar a bpf_ringbuf_reserve 15: si r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: llamar a bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: salir Para el primer caso, la exploración de la ejecución de una sola línea podará la búsqueda en insn 14 para la segunda rama de la rama insn 9, ya que se verificará primero utilizando r2 = -1 (UINT_MAX), mientras que como w1 en insn 9 siempre será 0, por lo que en tiempo de ejecución no obtenemos un error por ser mayor que UINT_MAX/4 de bpf_ringbuf_reserve. El verificador durante regsafe solo ve reg->precise como falso para ambos registros r2 en ambos estados, por lo tanto, los considera iguales para fines de states_equal. Si propagáramos marcadores precisos utilizando el soporte de retroceso, usaríamos el marcado preciso para asegurarnos de que el antiguo r2 (UINT_MAX) estuviera dentro del nuevo r2 (1) y esto nunca sería verdadero, por lo que la verificación fallaría legítimamente. El resultado final es que el acceso fuera de los límites en la instrucción 19 se permitiría sin esta corrección. Tenga en cuenta que reg->precise siempre se establece en verdadero cuando el usuario no tiene CAP_BPF (o cuando el recuento de subprocesos es mayor que 1 (es decir, uso de cualquier función estática o global)), por lo tanto, esto solo es un problema cuando las marcas de precisión deben propagarse explícitamente (es decir, usuarios privilegiados con CAP_BPF). Se ha incluido un caso de prueba simplificado en el próximo parche para evitar futuras regresiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/ttm: corrección del manejo de CCS Crucible + Mesa reciente parece a veces afectar: GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER) Y parece que también podemos activar esto con gem_lmem_swapping, si modificamos la prueba para usar tamaños de objeto ligeramente mayores. Mirando más de cerca, parece que tenemos los siguientes problemas en migration_copy(): - Estamos usando un entero simple en varios lugares, que podemos desbordar fácilmente con un objeto grande. - Pasamos el tamaño completo del objeto (cuando el src es lmem) a emit_pte() y luego intentamos copiarlo, lo cual no funciona, ya que solo tenemos unas pocas ventanas de tamaño fijo en las que mapear las páginas y realizar la copia. Con un objeto > 8M, por lo tanto, no estamos copiando correctamente las páginas. Y luego, con un objeto > 64M, activamos GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER). Por lo tanto, parece que nuestra gestión de copias para cualquier objeto > 8M (que es nuestro CHUNK_SZ) está actualmente inactiva en DG2. Caso de prueba: igt@gem_lmem_swapping (seleccionado de el commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Se corrige el error "use-after-free" durante la anulación del registro. En el siguiente código, dentro de firmware_upload_unregister(), la llamada a device_unregister() podría provocar que la función dev_release libere la estructura fw_upload_priv antes de que se desreferenciara para la llamada a module_put(). Este error fue detectado por el robot de pruebas del kernel mediante CONFIG_KASAN al ejecutar las autopruebas del firmware. device_unregister(&fw_sysfs->dev); module_put(fw_upload_priv->module); El problema se corrige copiando fw_upload_priv->module a una variable local para su uso al llamar a device_unregister().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: cm3605: Se corrige una ruta de gestión de errores en cm3605_probe(). El commit en Fixes (correcciones) también introdujo una nueva ruta de gestión de errores que debería enlazar con la ruta de gestión de errores existente. De lo contrario, se producirían fugas de recursos.<br />

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: iforce - reactivar tras borrar el indicador IFORCE_XMIT_RUNNING. syzbot informa que la tarea está bloqueada en __input_unregister_device() [1], ya que iforce_close() espera en wait_event_interruptible() con dev-&amp;gt;mutex retenido, lo que bloquea input_disconnect_device() desde __input_unregister_device(). Parece que la causa es simplemente que el commit c2b27ef672992a20 ("Entrada: iforce - esperar a que se complete el comando al cerrar el dispositivo") olvidó llamar a wake_up() después de clear_bit(). Se soluciona este problema mediante un asistente que llame a clear_bit() seguido de wake_up_all().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/rtas: Corrección del manejo de MSR[HV] de RTAS para Cell. Los cambios recientes en el manejo de MSR al ingresar RTAS (firmware) provocan bloqueos en las máquinas IBM Cell. Ejemplo de rastreo: el kernel intentó ejecutar la página de usuario (2fff01a8): ¿intento de explotación? (uid: 0) ERROR: No se puede controlar la obtención de instrucciones del núcleo Dirección de instrucción errónea: 0x2fff01a8 Oops: Acceso del núcleo al área defectuosa, firma: 11 [#1] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 Módulos de celda NUMA vinculados: CPU: 0 PID: 0 Comm: swapper/0 Contaminado: GW 6.0.0-rc2-00433-gede0a8d3307a #207 NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 000000000000000 REGS: c0000000015236b0 TRAP: 0400 Contaminado: GW (6.0.0-rc2-00433-gede0a8d3307a) MSR: 0000000008001002 CR: 00000000 XER: 20000000 ... NIP 0x2fff01a8 LR 0x32608 Rastreo de llamadas: 0xc00000000143c5f8 (no confiable) .rtas_call+0x224/0x320 .rtas_get_boot_time+0x70/0x150 .read_persistent_clock64+0x114/0x140 .read_persistent_wall_and_boot_offset+0x24/0x80 .timekeeping_init+0x40/0x29c A diferencia de las plataformas PAPR, donde RTAS solo se usa en huéspedes, en las máquinas IBM Cell, Linux se ejecuta con MSR[HV] activado, pero también usa RTAS, proporcionado por SLOF. Para solucionarlo, copie el bit MSR[HV] del valor MSR que acabamos de leer con mfmsr al valor usado para RTAS. Parece que también podríamos solucionarlo usando un #ifdef CELL para activar MSR[HV], pero esto no funciona, ya que es posible crear una única imagen de kernel que funcione tanto en Cell nativo como en pseries.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kcm: corrección del orden y la limpieza de strp_init(). strp_init() se llama solo unas líneas por encima de la comprobación csk-&amp;gt;sk_user_data; también inicializa strp-&amp;gt;work, etc., por lo que no es necesario llamar a strp_done() para cancelar el trabajo recién inicializado. Si KCM ya utiliza sk_user_data, no se debe modificar psock-&amp;gt;strp, en particular el estado strp-&amp;gt;work, por lo que es necesario mover strp_init() después de la comprobación csk-&amp;gt;sk_user_data. Esto también elimina la advertencia de lockdep reportada por syzbot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: corrige corrupción de memoria al abrir La comprobación de desbordamiento de duplicación de sesión de la sonda incrementó el recuento de sesiones también cuando no había más sesiones disponibles, de modo que la memoria más allá de la matriz de sesiones asignadas en bloques de tamaño fijo podía corromperse en fastrpc_session_alloc() al abrir().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: corregir corrupción de memoria en la sonda Agregue la verificación de cordura faltante en el recuento de sesiones sondeadas para evitar corromper la memoria más allá de la matriz de sesiones asignadas por bloques de tamaño fijo cuando hay más de FASTRPC_MAX_SESSIONS sesiones definidas en el árbol de dispositivos.