Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: mtk-pmic-keys - corrección de posible desreferencia de puntero nulo. En mtk_pmic_keys_probe, el parámetro regs solo se establece si el botón se analiza en el árbol de dispositivos. Sin embargo, en hardware donde el botón se deja flotante, es muy probable que se elimine ese nodo para no habilitar esa entrada. En ese caso, el código intentará desreferenciar un puntero nulo. En su lugar, usemos la estructura regs, tal como está definida para todas las plataformas compatibles. Tenga en cuenta que es posible establecer el registro de clave incluso si este último está deshabilitado, ya que la interrupción no se habilitará de todos modos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: corrección de acceso fuera de los límites durante la desfragmentación de elementos multienlace. Actualmente, durante el proceso de desfragmentación de elementos multienlace, la longitud de este elemento se sumaba a la longitud total de los elementos de entrada (IE) al calcular la longitud de los elementos de entrada restantes después del elemento multienlace en cfg80211_defrag_mle(). Esto podría provocar un acceso fuera de los límites si el elemento multienlace o sus elementos de fragmento correspondientes son los últimos elementos en el búfer de los elementos de entrada. Para solucionar este problema, calcule correctamente la longitud de los elementos de entrada restantes restando el desplazamiento final del elemento multienlace del desplazamiento final total de los elementos de entrada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/pci: Se corrige la falta de comprobación para el retorno del error zpci_create_device(). La función zpci_create_device() devuelve un puntero de error que debe comprobarse antes de desreferenciarlo como puntero struct zpci_dev. Se añade la comprobación faltante en __clp_add(), donde se omitió al añadir la lista de escaneo en el commit corregida. Simplemente no añadir el dispositivo a la lista de escaneo provoca el comportamiento anterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrección de error de contexto no válido en el asistente dml [Por qué] Error "BUG: función inactiva llamada desde un contexto no válido". Después: "drm/amd/display: Proteger FPU en dml2_validate()/dml21_validate()". La función populate_dml_plane_cfg_from_plane_state() utiliza el indicador GFP_KERNEL para la asignación de memoria, que no debería usarse en contextos atómicos. Esta asignación solo es necesaria para usar otra función auxiliar, get_scaler_data_for_plane(). [Cómo] Modificar los asistentes para que pasen un puntero a scaler_data dentro del contexto existente, eliminando la necesidad de asignar/desasignar memoria dinámicamente y copiar. (Seleccionado de el commit bd3e84bc98f81b44f2c43936bdadc3241d654259)

Los límites de adivinación de contraseñas se pueden eludir al utilizar la autenticación LDAP.

La respuesta en caso de inicio de sesión fallido podría ser diferente dependiendo de si el nombre de usuario era local o central.

El protocolo de descubrimiento OpenFlow puede agotar los recursos porque no tiene límite de velocidad

La limitación incorrecta de la ruta de acceso en las aplicaciones de aprovisionamiento de circuitos e importación de archivos permite la modificación y carga de archivos

Un usuario autenticado puede modificar los datos del estado de la aplicación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/huge_memory: se corrige la desreferenciación de una entrada de migración de PMD no válida. Al migrar un THP, el acceso simultáneo a la entrada de migración de PMD durante un escaneo dividido diferido puede provocar un acceso no válido a una dirección, como se ilustra a continuación. Para evitar este acceso no válido, es necesario comprobar la entrada de migración de PMD y regresar antes. En este contexto, no es necesario usar pmd_to_swp_entry ni pfn_swap_entry_to_page para verificar la igualdad del folio de destino. Dado que la entrada de migración de PMD está bloqueada, no puede servir como destino. Discusión y explicación de Hugh Dickins en la lista de correo: "Una búsqueda anon_vma apunta a una ubicación que podría contener el folio de interés, pero que en su lugar podría contener otro folio: y eliminar esos otros folios es precisamente para lo que sirve la comprobación "folio != pmd_folio((*pmd)" (y el comentario "riesgo de reemplazar el folio equivocado" unas líneas más arriba)." ERROR: no se puede gestionar el fallo de página para la dirección: ffffea60001db008 CPU: 0 UID: 0 PID: 2199114 Comm: tee No contaminado 6.14.0+ #4 NINGUNO Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010: pmd_enorme_división_bloqueada+0x3b5/0x2b60 Rastreo de llamadas: try_to_migrate_one+0x28c/0x3730 rmap_walk_anon+0x4f6/0x770 unmap_folio+0x196/0x1f0 split_huge_page_to_list_to_order+0x9f6/0x1560 deferred_split_scan+0xac5/0x12a0 shrinker_debugfs_scan_write+0x376/0x470 full_proxy_write+0x15c/0x220 vfs_write+0x2fc/0xcb0 ksys_write+0x146/0x250 do_syscall_64+0x6a/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e El error fue detectado por syzkaller en un kernel interno, y luego confirmado en upstream.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Depuración de paquetes en bpf_redirect_peer. Cuando se usa bpf_redirect_peer para redirigir paquetes a un dispositivo en otro espacio de nombres de red, el skb no se depura. Esto puede provocar que la información de skb de un espacio de nombres se utilice indebidamente en otro. Por ejemplo, esto provoca que Cilium descarte tráfico al usar bpf_redirect_peer para redirigir paquetes que acaban de pasar por el descifrado de IPsec a un espacio de nombres de contenedor. El siguiente seguimiento de pwru muestra (1) la ruta del paquete desde la capa XFRM del host hasta la capa XFRM del contenedor, donde se descarta, y (2) el número de extensiones skb activas en cada función. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2. En este caso, no hay políticas XFRM en el espacio de nombres de red del contenedor, por lo que la pérdida es inesperada. Al descifrar el paquete IPsec, el estado XFRM utilizado para el descifrado se configura en las extensiones skb. Esta información se conserva en el conmutador netns. Al llegar a la comprobación de la política XFRM en las redes netn del contenedor, __xfrm_policy_check descarta el paquete con LINUX_MIB_XFRMINNOPOLS porque no se encuentra una política XFRM (del lado del contenedor) que coincida con el estado XFRM (del lado del host) utilizado para el descifrado. Este parche corrige este problema depurando el paquete al usar bpf_redirect_peer, como se hace en conmutadores netn típicos a través de dispositivos veth, excepto que skb->mark y skb->tstamp no se ponen a cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memblock: aceptar memoria asignada antes de su uso en memblock_double_array(). Al aumentar el tamaño de la matriz en memblock_double_array() y la losa aún no está disponible, se utiliza una llamada a memblock_find_in_range() para reservar/asignar memoria. Sin embargo, es posible que no se haya aceptado el rango devuelto, lo que puede provocar un bloqueo al iniciar un invitado SNP: RIP: 0010:memcpy_orig+0x68/0x130 Código: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b Para mitigar este problema, llame a accept_memory() en el rango de memoria devuelto antes de que el slab esté disponible. Antes de la versión 6.12, la interfaz accept_memory() utilizaba los parámetros "start" y "end" en lugar de "start" y "size". Por lo tanto, la llamada a accept_memory() debe ajustarse para especificar "start + size" en lugar de "end" al aplicarlo a kernels anteriores a la versión 6.12.