Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: mst: corrige el uso sospechoso de rcu en br_mst_set_state Convertí br_mst_set_state a RCU para evitar un use-after-free de VLAN, pero olvidé cambiar el asistente de desreferencia del grupo VLAN. Cambie al asistente deref de RCU del grupo vlan para corregir la advertencia de uso sospechoso de rcu.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: mst: pasar grupo vlan directamente a br_mst_vlan_set_state Pase el puntero del grupo vlan ya obtenido a br_mst_vlan_set_state() en lugar de desreferenciarlo nuevamente. Cada persona que llama ya lo ha desreferenciado correctamente para su contexto. Este cambio es necesario para la siguiente corrección sospechosa de desreferencia de RCU. No se pretenden cambios funcionales.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/dpt: hacer que el objeto DPT no se pueda reducir. En algunos escenarios, el objeto DPT se reduce pero el framebuffer real no y, por lo tanto, sigue ahí en vm->bound_list del DPT. Luego intenta reescribir las PTE mediante una asignación de CPU obsoleta. Esto provoca pánico. [vsyrjala: Agregar comentario TODO] (seleccionado del commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: Manejar el borrado de TD para el caso de múltiples flujos Cuando se utilizan múltiples flujos, es posible que haya múltiples TD en vuelo cuando se detiene un endpoint. Necesitamos emitir un puntero de salida de cola TR para cada uno, para garantizar que todo se restablezca correctamente y se borren los cachés. Cambie la lógica para que cualquier N>1 TD que se encuentre activo para diferentes flujos se difiera hasta después de que se procese el primero, llamando a xhci_invalidate_cancelled_tds() nuevamente desde xhci_handle_cmd_set_deq() para poner en cola otro comando hasta que hayamos terminado con todos ellos. También cambie las rutas de error/"nunca debería suceder" para asegurarnos de que al menos borramos los TD afectados, incluso si no podemos emitir un comando para borrar el caché del hardware, y quejarnos en voz alta con un xhci_warn() si esto alguna vez sucede. Este caso de problema se remonta al commit e9df17eb1408 ("USB: xhci: Suposiciones correctas sobre el número de anillos por endpoint.") al principio de la vida del controlador XHCI, cuando se agregó por primera vez el soporte de transmisión. Luego se identificó, pero no se solucionó ni se convirtió en una advertencia en el commit 674f8438c121 ("xhci: dividir el manejo de endpoints detenidos en dos pasos"), que agregó un comentario FIXME para el caso del problema (sin cambiar materialmente el comportamiento, hasta donde yo sé). , aunque la nueva lógica hizo que el problema fuera más obvio). Luego, más tarde, en el commit 94f339147fc3 ("xhci: Se corrigió el error al devolver algunas URB canceladas en caché"), se reconoció nuevamente. [Mathias: commit 94f339147fc3 ("xhci: Se corrigió el error al devolver algunas URB canceladas en caché") fue una solución de regresión específica para el parche mencionado anteriormente. Los usuarios informaron problemas con el USB atascado después de desmontar/desconectar dispositivos UAS. Esto revirtió la limpieza de TD de múltiples transmisiones a su estado original.] Aparentemente, el autor de el commit estaba al tanto del problema (pero aún así decidió enviarlo): todavía se mencionaba como FIXME, se agregó un xhci_dbg() para registrar el condición del problema y el problema restante se mencionó en la descripción de El commit. La elección de crear el tipo de registro xhci_dbg() para lo que, en este momento, es una condición rota completamente no controlada y conocida es desconcertante y desafortunada, ya que garantiza que ningún usuario real verá el registro en producción, lo que lo hace casi no depurable ( de hecho, incluso si activa DEBUG, el mensaje realmente no indica que haya ningún problema). Me tomó *meses* de fallas aleatorias de xHC para finalmente encontrar una reproducción confiable y poder realizar una sesión de depuración profunda, que podría haberse evitado si esta condición rota y no controlada se hubiera informado con una advertencia, como debería haber sido. ha sido un error que se dejó intencionalmente sin corregir (sin importar que no debería haberse dejado en absoluto). > Se necesita otra solución para solucionar el borrado de los cachés de todos los anillos de transmisión con > TD cancelados, pero no es tan urgente. 3 años después de esa declaración y 14 años después de que se introdujo el error original, creo que finalmente es hora de solucionarlo. Y tal vez la próxima vez no dejemos errores sin corregir (que en realidad son peores que el error original), y hagamos que la gente revise las confirmaciones del kernel, por favor. Soluciona fallas de xHC y fallas de IOMMU con dispositivos UAS al manejar errores/fallas. La reproducción más sencilla es usar `hdparm` para marcar un sector inicial (por ejemplo, 1024) en un disco como defectuoso, luego `cat /dev/sdX > /dev/null` en un bucle. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: verifique n_ssids antes de acceder a los ssids en algunas versiones de cfg80211, el punto ssids puede ser válido aunque n_ssids sea 0. Accediendo al puntero en este caso provocará un acceso fuera de los límites. Solucione este problema comprobando primero n_ssids.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: asegúrese de que snd_una se inicialice correctamente al conectarse. Esto está estrictamente relacionado con el commit fb7a0d334894 ("mptcp: asegúrese de que snd_nxt se inicialice correctamente al conectarse"). Resulta que syzkaller puede activar la retransmisión después del respaldo y antes de procesar cualquier otro paquete entrante, de modo que snd_una aún permanece sin inicializar. Solucione el problema al inicializar explícitamente snd_una junto con snd_nxt y write_seq.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/exynos/vidi: corrige la pérdida de memoria en .get_modes() El EDID duplicado nunca se libera. Arreglalo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: logitech-dj: Reparar pérdida de memoria en logi_dj_recv_switch_to_dj_mode() Reparar una pérdida de memoria en la ruta de error logi_dj_recv_send_report().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethtool: corrige la condición de error en ethtool_get_phy_stats_ethtool() Advertencia del verificador estático de Clang (scan-build): net/ethtool/ioctl.c:line 2233, column 2 Puntero de función llamada es nulo (desreferencia nula). Devuelva '-EOPNOTSUPP' cuando 'ops->get_ethtool_phy_stats' sea NULL para corregir este error tipográfico.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige un posible use-after-free en bpf_link_free() Después del commit 1a80dbcb2dba, bpf_link se puede liberar mediante link->ops->dealloc_deferred, pero el código aún prueba y usa link->ops->dealloc después, lo que conduce a un use-after-free según lo informado por syzbot. En realidad, uno de ellos debería ser suficiente, así que llame a uno de ellos en lugar de a ambos. También agregue WARN_ON() en caso de cualquier implementación problemática.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: memblock: make memblock_set_node() también advierte sobre el uso de MAX_NUMNODES En un sistema x86 (antiguo) con SRAT que solo cubre espacio superior a 4 Gb: ACPI: SRAT: Nodo 0 PXM 0 [mem 0x100000000 -0xfffffffff] hotplug, El commit a la que se hace referencia a continuación hace que esta configuración NUMA ya no sea rechazada por un kernel CONFIG_NUMA=y (anteriormente NUMA: los nodos solo cubren 6144 MB de su RAM e820 de 8185 MB. No se usa. No se encontró ninguna configuración NUMA Falsificar un nodo en [mem 0x0000000000000000-0x000000027fffffff] se vio en el registro directamente después del mensaje citado anteriormente), debido a que memblock_validate_numa_coverage() verifica NUMA_NO_NODE (solamente). Esto a su vez llevó a la advertencia de memblock_alloc_range_nid() sobre la activación de MAX_NUMNODES, seguida de una deref NULL en memmap_init() al intentar acceder a los datos del nodo 64 (NODE_SHIFT=6). Para compensar dicho cambio, active memblock_set_node() y ajuste un valor pasado de MAX_NUMNODES, tal como lo hacen otras funciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: intenta corregir fallas de segmentación aleatoria en compilaciones de paquetes. Los sistemas PA-RISC con procesadores PA8800 y PA8900 han tenido problemas con fallas de segmentación aleatoria durante muchos años. Los sistemas con procesadores anteriores son mucho más estables. Los sistemas con procesadores PA8800 y PA8900 tienen una gran caché L2 que necesita un vaciado por página para un rendimiento decente cuando se vacía un rango grande. La caché combinada en estos sistemas también es más sensible a alias no equivalentes que las cachés de sistemas anteriores. La mayoría de los fallos de segmentación aleatoria que he observado parecen ser daños en la memoria asignada mediante mmap y malloc. Mi primer intento de solucionar los fallos aleatorios no funcionó. Al revisar el código de caché, me di cuenta de que había dos problemas que el código existente no manejaba correctamente. Ambos se relacionan con la entrada de caché. Otro problema es que la actualidad en las PTE es picante. 1) Los cachés PA-RISC tienen mente propia y pueden cargar especulativamente datos e instrucciones para una página siempre que haya una entrada en el TLB para la página que permita la entrada. Los TLB son locales para cada CPU. Por lo tanto, la entrada TLB de una página debe eliminarse antes de eliminarla. Esto es particularmente importante en los sistemas SMP. En algunas de las rutinas de vaciado, se llamaría a la rutina de vaciado y luego se purgaría la entrada TLB. Esto se debía a que la rutina de lavado necesitaba la entrada TLB para realizar el lavado. 2) Mi enfoque inicial para intentar solucionar las fallas aleatorias fue intentar usar Flush_cache_page_if_present para todas las operaciones de descarga. En realidad, esto empeoró las cosas y provocó un par de bloqueos de hardware. Finalmente me di cuenta de que algunas líneas no se estaban borrando porque el código de verificación del pte era picante. Esto resultó en asignaciones aleatorias no equivalentes a páginas físicas. La descarga tmpalias __flush_cache_page configura su propia entrada TLB y no necesita la entrada TLB existente. Siempre que podamos encontrar el puntero pte de la página vm, podemos obtener el pfn y la dirección física de la página. También podemos purgar la entrada TLB de la página antes de realizar el vaciado. Además, __flush_cache_page utiliza una entrada TLB especial que inhibe la entrada de caché. Al cambiar las asignaciones de páginas, debemos asegurarnos de que las líneas se eliminen del caché. No es suficiente simplemente borrar las líneas de la memoria, ya que pueden volver. Esto dejó en claro que necesitábamos implementar todas las operaciones de vaciado necesarias utilizando rutinas tmpalias. Esto incluye vaciados para páginas de usuario y de kernel. Después de modificar el código para usar tmpalias vaciados, quedó claro que los errores de segmentación aleatoria no se resolvieron por completo. La frecuencia de fallas fue peor en sistemas con 64 MB L2 (PA8900) y sistemas con más CPU (rp4440). La advertencia que agregué a Flush_cache_page_if_present para detectar páginas que no se podían vaciar se activaba con frecuencia en algunos sistemas. Helge y yo miramos las páginas que no se podían vaciar y descubrimos que la PTE estaba vacía o era una página de intercambio. Ignorar las páginas que se intercambiaron parecía estar bien, pero las páginas con PTE borradas parecían problemáticas. Miré rutinas relacionadas con pte_clear y noté ptep_clear_flush. La implementación predeterminada simplemente vacía la entrada TLB. Sin embargo, era obvio que en París también necesitamos vaciar la página de caché. Si no limpiamos la página de caché, quedarán líneas obsoletas en la caché y provocarán daños aleatorios. Una vez que se borra una PTE, no hay forma de encontrar la dirección física asociada con la PTE y borrar la página asociada más adelante. ---truncado---