Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: corrección del bloqueo de PT de hugetlb frente a core-mm Recientemente hicimos que el código de recorrido de tabla de páginas común de GUP también recorriera VMA hugetlb sin la mayoría de las mayúsculas y minúsculas especiales de hugetlb, preparándonos para el futuro de tener menos código de recorrido de tabla de páginas específico de hugetlb en la base de código. Resulta que nos perdimos un detalle de bloqueo de tabla de páginas: el bloqueo de tabla de páginas para folios hugetlb que no están mapeados usando un solo PMD/PUD. Supongamos que tenemos un folio hugetlb que abarca múltiples PTE (por ejemplo, folios hugetlb de 64 KiB en arm64 con un tamaño de página base de 4 KiB). GUP, mientras recorre las tablas de páginas, realizará un pte_offset_map_lock() para agarrar el bloqueo de tabla PTE. Sin embargo, hugetlb que modifica simultáneamente estas tablas de páginas en realidad agarraría el mm->page_table_lock: con USE_SPLIT_PTE_PTLOCKS, los bloqueos serían diferentes. Algo similar puede suceder ahora mismo con folios hugetlb que abarcan múltiples PMD cuando USE_SPLIT_PMD_PTLOCKS. Este problema se puede reproducir [1], por ejemplo, activando: [ 3105.936100] ------------[ cortar aquí ]------------ [ 3105.939323] ADVERTENCIA: CPU: 31 PID: 2732 en mm/gup.c:142 try_grab_folio+0x11c/0x188 [ 3105.944634] Módulos vinculados en: [...] [ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer No contaminado 6.10.0-64.eln141.aarch64 #1 [ 3105.980406] Nombre del hardware: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 24/05/2024 [ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3105.991108] pc : try_grab_folio+0x11c/0x188 [ 3105.994013] lr : follow_page_pte+0xd8/0x430 [ 3105.996986] sp : ffff80008eafb8f0 [ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43 [ 3106.004414] x26: 0000000000000001 x25: 00000000000000000 x24: ffff80008eafba48 [ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978 [ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001 [ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffffff x15: 0000000000000000 [ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000 [ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9: ffffb854771b12f0 [ 3106.034324] x8: 000800000000000 x7: ffff7a546c1aa980 x6: 0008000000000080 [ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000 [ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000 [ 3106.047957] Rastreo de llamadas: [ 3106.049522] try_grab_folio+0x11c/0x188 [ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0 [ 3106.055527] follow_page_mask+0x1a0/0x2b8 [ 3106.058118] __get_user_pages+0xf0/0x348 [ 3106.060647] faultin_page_range+0xb0/0x360 [ 3106.063651] do_madvise+0x340/0x598 Hagamos que huge_pte_lockptr() use efectivamente los mismos bloqueos PT que cualquier rastreador de tablas de páginas core-mm haría. Agregue ptep_lockptr() para obtener el bloqueo de la tabla de páginas PTE usando un puntero pte - desafortunadamente no podemos convertir pte_lockptr() porque virt_to_page() no funciona con tablas de páginas kmap'ed que podemos tener con CONFIG_HIGHPTE. Maneje CONFIG_PGTABLE_LEVELS correctamente verificando en orden inverso, de modo que cuando, por ejemplo, CONFIG_PGTABLE_LEVELS==2 con PGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE funcionará como se espera. Documente por qué funciona eso. Hay un caso desagradable: powerpc 8xx, en el que tenemos un folio hugetlb de 8 MiB que se asigna utilizando dos tablas de páginas PTE. Mientras hugetlb quiere tomar el bloqueo de la tabla PMD, core-mm tomaría el bloqueo de la tabla PTE de una de ambas tablas de páginas PTE. En tales casos extremos, tenemos que asegurarnos de que ambos bloqueos coincidan, lo que (¡afortunadamente!) --- truncado ----

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: Comprueba que xhci->interrupters se asignen en xhci_mem_clearup() Si xhci_mem_init() falla, llama a xhci_mem_cleanup() para limpiar el daño. Si falla lo suficientemente pronto, antes de que se asigne xhci->interrupters pero después de que se haya establecido xhci->max_interrupters, lo que sucede en la mayoría (¿todos?) de los casos, las cosas se ponen peor, ya que xhci_mem_cleanup() desreferencia incondicionalmente a xhci->interrupters. Con prejuicio. Bloquea el bucle de liberación de interrupciones con una comprobación de que xhci->interrupters no sea NULL. Se encontró mientras se depuraba un problema de asignación de DMA que llevó al controlador XHCI por este camino exacto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: maneja valores MAX_SKB_FRAGS grandes Sabrina informa que el controlador igb no maneja bien valores MAX_SKB_FRAG grandes: configurar MAX_SKB_FRAG en 45 causa corrupción de payload en TX. Un reproductor fácil es ejecutar ssh para conectarse a la máquina. Con MAX_SKB_FRAGS=17 funciona, con MAX_SKB_FRAGS=45 falla. Esto se informó originalmente en https://bugzilla.redhat.com/show_bug.cgi?id=2265320 La causa raíz del problema es que el controlador no tiene en cuenta correctamente el tamaño de información compartida (posiblemente grande) al seleccionar el diseño de anillo, e intentará ajustar dos paquetes dentro de la misma página de 4K incluso cuando la primera lista de fragmentos prevalecerá sobre la segunda cabeza. Aborde el problema verificando si los búferes de 2K son insuficientes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcmfmac: cfg80211: Manejar la eliminación de pmksa basada en SSID wpa_supplicant 2.11 envía desde 1efdba5fdc2c ("Manejar la eliminación de PMKSA en el controlador para casos de descarga SAE/OWE") Comandos del de PMKSA basados en SSID. brcmfmac no está preparado e intenta desreferenciar los punteros NULL bssid y pmkid en cfg80211_pmksa. Las operaciones PMKID_V3 admiten actualizaciones basadas en SSID, por lo que copia el SSID.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg_write_event_control(): corrige un error que puede ser activado por el usuario. Oops, *no* tenemos garantía de que todo lo que esté más allá del NUL de terminación se asigne (y mucho menos se inicialice con algo sensato).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: se corrige la asignación de páginas si vm_area_alloc_pages() con un retroceso de orden superior al orden 0 __vmap_pages_range_noflush() asume que su argumento pages** contiene páginas con el mismo cambio de página. Sin embargo, desde el commit e9c3cda4d86e ("mm, vmalloc: se corrigen las asignaciones de orden superior __GFP_NOFAIL"), si gfp_flags incluye __GFP_NOFAIL con orden superior en vm_area_alloc_pages() y la asignación de páginas falla para el orden superior, pages** puede contener dos cambios de página diferentes (orden superior y orden 0). Esto podría provocar que __vmap_pages_range_noflush() realice asignaciones incorrectas, lo que podría provocar una corrupción de memoria. Los usuarios pueden encontrarse con esto de la siguiente manera (vmap_allow_huge = true, 2M es para PMD_SIZE): kvmalloc(2M, __GFP_NOFAIL|GFP_X) __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP) vm_area_alloc_pages(order=9) ---> la asignación del pedido 9 falló y se vuelve al pedido 0 vmap_pages_range() vmap_pages_range_noflush() __vmap_pages_range_noflush(page_shift = 21) ----> ocurre una asignación incorrecta Podemos eliminar el código de respaldo porque si falla una asignación de orden alto, __vmalloc_node_range_noprof() volverá a intentarlo con el pedido 0. Por lo tanto, no es necesario volver al pedido 0 aquí. Por lo tanto, solucione esto eliminando el código de respaldo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: se corrige la corrupción de mapas de bits en close_range() con CLOSE_RANGE_UNSHARE Se espera que copy_fd_bitmaps(new, old, count) copie los primeros bits count/BITS_PER_LONG de old->full_fds_bits[] y rellene el resto con ceros. Lo que hace es copiar suficientes palabras (BITS_TO_LONGS(count/BITS_PER_LONG)), luego memsets el resto. Eso funciona bien, *si* todos los bits más allá del punto de corte están limpios. De lo contrario, corremos el riesgo de basura de la última palabra que habíamos copiado. Para la mayoría de los llamadores, esto es cierto: expand_fdtable() tiene count igual a old->max_fds, por lo que no hay descriptores abiertos más allá de count, y mucho menos palabras completamente ocupadas en ->open_fds[], que es a lo que corresponden los bits en ->full_fds_bits[]. El otro llamador (dup_fd()) pasa sane_fdtable_size(old_fdt, max_fds), que es el múltiplo más pequeño de BITS_PER_LONG que cubre todos los descriptores abiertos por debajo de max_fds. En el caso común (copiar en fork()) max_fds es ~0U, por lo que todos los descriptores abiertos estarán por debajo de él y estamos bien, por las mismas razones por las que la llamada en expand_fdtable() es segura. Desafortunadamente, hay un caso en el que max_fds es menor que eso y en el que, de hecho, podríamos terminar con basura en ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) con * tabla de descriptores que se comparte actualmente * 'to' está por encima de la capacidad actual de la tabla de descriptores * 'from' está justo debajo de algún trozo de descriptores abiertos. En ese caso, terminamos con un comportamiento observablemente incorrecto, por ejemplo, generar un hijo con CLONE_FILES, obtener todos los descriptores en el rango 0..127 abiertos, luego close_range(64, ~0U, CLOSE_RANGE_UNSHARE) y ver que dup(0) termina con el descriptor #128, a pesar de que #64 no está abierta observablemente. La solución mínimamente invasiva sería lidiar con eso en dup_fd(). Si esto demuestra agregar una sobrecarga medible, podemos ir por ese camino, pero intentemos arreglar copy_fd_bitmaps() primero. * nuevo ayudante: bitmap_copy_and_expand(to, from, bits_to_copy, size). * hacer que copy_fd_bitmaps() tome el tamaño del mapa de bits en palabras, en lugar de bits; Su argumento 'count' es siempre un múltiplo de BITS_PER_LONG, por lo que no perdemos ninguna información y de esa manera podemos usar el mismo asistente para los tres mapas de bits: el compilador verá que count es un múltiplo de BITS_PER_LONG para los grandes, por lo que generará memcpy()+memset() simple. Se agregó el reproductor a tools/testing/selftests/core/close_range_test.c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/dasd: se corrige la recuperación de errores que provoca la corrupción de datos en dispositivos ESE Los volúmenes con aprovisionamiento ligero o Eficiencia de espacio de extensión (ESE) deben formatearse a pedido durante el procesamiento de E/S habitual. La función dasd_ese_needs_format comprueba los códigos de error que indican la inexistencia de un formato de pista adecuado. La comprobación de longitud incorrecta es demasiado imprecisa, ya que otros casos de error que provocan el transporte de datos insuficientes también tienen esta bandera activada. Esto puede provocar la corrupción de datos en ciertos casos de error, por ejemplo, durante el arranque en caliente de un servidor de almacenamiento. Se soluciona eliminando la comprobación de longitud incorrecta y reemplazándola por una comprobación explícita de formato de pista no válido en el modo de transporte. También se elimina la comprobación de archivo protegido, ya que este no es un caso válido de manejo de ESE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: mmc_test: Se corrige la desreferencia NULL en caso de error de asignación. Si la asignación "test->highmem = alloc_pages()" falla, al llamar a __free_pages(test->highmem) se obtendrá una desreferencia NULL. Cambie también el código de error a -ENOMEM en lugar de devolver un resultado positivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: tegra: No marcar dispositivos ACPI como seguros para irq En máquinas ACPI, el módulo tegra i2c encuentra un problema debido a que se llama a un mutex dentro de un spinlock. Esto lleva al siguiente error: BUG: función dormida llamada desde un contexto no válido en kernel/locking/mutex.c:585 ... Rastreo de llamada: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xfer El problema surge porque durante __pm_runtime_resume(), se adquiere el spinlock &dev->power.lock antes de que se llame a rpm_resume(). Más tarde, rpm_resume() invoca acpi_subsys_runtime_resume(), que se basa en mutexes, lo que activa el error. Para solucionar este problema, los dispositivos en ACPI ahora están marcados como no seguros para IRQ, considerando la dependencia de acpi_subsys_runtime_resume() en los mutex.

Las versiones 24.4.1, 23.6.6 y anteriores de Audition se ven afectadas por una vulnerabilidad de lectura fuera de los límites que podría provocar la divulgación de memoria confidencial. Un atacante podría aprovechar esta vulnerabilidad para eludir mitigaciones como ASLR. La explotación de este problema requiere la interacción del usuario, ya que la víctima debe abrir un archivo malicioso.

COMFAST CF-XR11 V2.7.2 tiene una vulnerabilidad de inyección de comandos en la función sub_424CB4. Los atacantes pueden enviar mensajes de solicitud POST a /usr/bin/webmgnt e inyectar comandos en el parámetro iface.