Linux Kernel hasta 6.1.10 find_pmd_or_thp_or_none escalada de privilegios

| CVSS Puntuación meta temporal | Precio actual del exploit (≈) | Puntuación de interés CTI |
|---|---|---|
| 4.5 | $0-$5k | 0.00 |
Resumen
Una vulnerabilidad clasificada como problemática fue encontrada en Linux Kernel hasta 6.1.10. Resulta afectada una función desconocida. La alteración resulta en escalada de privilegios. La vulnerabilidad es identificada como CVE-2023-52934. Ningún exploit está disponible. El mejor modo sugerido para mitigar el problema es actualizar a la última versión.
Detalles
Una vulnerabilidad ha sido encontrada en Linux Kernel hasta 6.1.10 y clasificada como problemática. La función find_pmd_or_thp_or_none es afectada por esta vulnerabilidad. Mediante la manipulación de un input desconocido se causa una vulnerabilidad de clase escalada de privilegios. Los efectos exactos de un ataque con éxito no son conocidos. CVE resume:
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups En el commit 34488399fa08 ("mm/madvise: agregar soporte de archivo y shmem a MADV_COLLAPSE") realizamos el siguiente cambio en find_pmd_or_thp_or_none(): - if (!pmd_present(pmde)) - return SCAN_PMD_NULL; + if (pmd_none(pmde)) + return SCAN_PMD_NONE; Esto era para uso de las rutas de código de archivo/shmem MADV_COLLAPSE, donde MADV_COLLAPSE podría identificar una hugepage asignada a pte, solo para que khugepaged entrara en carrera, liberara la tabla pte y borrara el pmd. Tales rutas de código incluyen: A) Si encontramos una página compuesta adecuadamente alineada de orden HPAGE_PMD_ORDER ya en el pagecache. B) En retract_page_tables(), si no logramos obtener mmap_lock para el mm/dirección objetivo. En estos casos, collapse_pte_mapped_thp() realmente espera un pmd none (no solo !present), y queremos identificar adecuadamente ese caso separado del caso donde no se encuentra ningún pmd, o es un bad-pmd (por supuesto, muchas cosas podrían suceder una vez que eliminamos mmap_lock, y el pmd podría plausiblemente sufrir múltiples transiciones debido a la intervención de un fallo, división, etc.). En cualquier caso, el código está preparado para instalar un huge-pmd solo cuando la entrada pmd existente es un pte-table-mapping-pmd genuino, o el none-pmd. Sin embargo, la confirmación introduce un agujero lógico; Es decir, hemos permitido que los !none- && !huge- && !bad-pmds se clasifiquen como pte-table-mapping-pmds genuinos. Un ejemplo de fugas de información son las entradas de intercambio. Los valores de pmd no se comprueban de nuevo antes de su uso en pte_offset_map_lock(), que espera nada menos que un pte-table-mapping-pmd genuino. Queremos restablecer la comprobación de !pmd_present() (debajo de la comprobación de pmd_none()), pero debemos tener cuidado con las sutilezas en las transiciones y los tratamientos de pmd por parte de varias arquitecturas. El problema es que __split_huge_pmd_locked() borra temporalmente el bit presente (o marca la entrada como inválida), pero pmd_present() y pmd_trans_huge() aún deben devolver verdadero mientras el pmd esté en este estado transitorio. Por ejemplo, pmd_present() de x86 también verifica _PAGE_PSE, la versión de riscv también verifica el bit _PAGE_LEAF y arm64 también verifica el bit PMD_PRESENT_INVALID. Cubriendo los 4 casos para x86 (todas las verificaciones realizadas en el mismo valor pmd): 1) pmd_present() y pmd_trans_huge(). Lo único que sabemos es que el bit PSE está establecido. O bien: a) No estamos compitiendo con __split_huge_page(), y PRESENT o PROTNONE están establecidos. => huge-pmd. b) Actualmente estamos compitiendo con __split_huge_page(). El peligro aquí es que procedamos como si tuviéramos un huge-pmd, pero en realidad estamos viendo un pte-mapping-pmd. Entonces, ¿cuál es el riesgo de este peligro? La única ruta relevante es: madvise_collapse() -> colapso_pte_mapped_thp(). Donde podríamos informar incorrectamente de "éxito", cuando en realidad la memoria no está respaldada por pmd. Esto no tiene problema, ya que la división podría ocurrir inmediatamente después de una ejecución (realmente) exitosa de madvise_collapse(). Por lo tanto, se puede asumir con seguridad que es huge-pmd. 2) pmd_present() && !pmd_trans_huge(): a) PSE no definido y PRESENT o PROTNONE sí lo están. => pte-table-mapping pmd (o PROT_NONE). b) devmap. Esta rutina puede llamarse inmediatamente después de desbloquear/bloquear mmap_lock, o sin bloqueos (véase khugepaged_scan_mm_slot()), por lo que las comprobaciones VMA anteriores han sido invalidadas. 3) !pmd_present() && pmd_trans_huge(): No es posible. 4) !pmd_present() && !pmd_trans_huge() Ni PRESENT ni PROTNONE se establecen => no presente. He revisado todas las arquitecturas que implementan pmd_trans_huge() (arm64, riscv, powerpc, longarch, x86, mips, s390) y esta lógica se traduce aproximadamente ---truncated---El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2023-52934. Resulta difícil de explotar. Hay detalles técnicos conocidos, pero no se dispone de un exploit.
Una actualización a la versión 6.1.11 elimina esta vulnerabilidad. Aplicando el parche 96aaaf8666010a39430cecf8a65c7ce2908a030f/edb5d0cf5525357652aff6eacd9850b8ced07143 es posible eliminar el problema. El parche puede ser descargado de git.kernel.org. El mejor modo sugerido para mitigar el problema es Actualización.
La vulnerabilidad también está documentado en la base de datos CERT Bund (WID-SEC-2025-0649). If you want to get best quality of vulnerability data, you may have to visit VulDB.
Afectado
- Google Container-Optimized OS
- Debian Linux
- Amazon Linux 2
- Red Hat Enterprise Linux
- Ubuntu Linux
- SUSE Linux
- Oracle Linux
- SUSE openSUSE
- Dell Avamar
- Open Source Linux Kernel
- SolarWinds Security Event Manager
- Dell NetWorker
- Dell Secure Connect Gateway
Producto
Escribe
Proveedor
Nombre
Versión
Licencia
Sitio web
- Proveedor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔍VulDB Confiabilidad: 🔍
CVSSv3
VulDB Puntuación meta base: 4.6VulDB Puntuación meta temporal: 4.6
VulDB Puntuación base: 4.6
VulDB Puntuación temporal: 4.4
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍
NVD Puntuación base: 4.7
NVD Vector: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complejidad | Autenticación | Confidencialidad | Integridad | Disponibilidad |
|---|---|---|---|---|---|
| Desbloquear | Desbloquear | Desbloquear | Desbloquear | Desbloquear | Desbloquear |
| Desbloquear | Desbloquear | Desbloquear | Desbloquear | Desbloquear | Desbloquear |
| Desbloquear | Desbloquear | Desbloquear | Desbloquear | Desbloquear | Desbloquear |
VulDB Puntuación base: 🔍
VulDB Puntuación temporal: 🔍
VulDB Confiabilidad: 🔍
Explotación
Clase: Escalada de privilegiosCWE: CWE-371
CAPEC: 🔍
ATT&CK: 🔍
Físico: En parte
Local: Sí
Remoto: En parte
Disponibilidad: 🔍
Estado: No está definido
EPSS Score: 🔍
EPSS Percentile: 🔍
Predicción de precios: 🔍
Estimación del precio actual: 🔍
| 0-Day | Desbloquear | Desbloquear | Desbloquear | Desbloquear |
|---|---|---|---|---|
| Hoy | Desbloquear | Desbloquear | Desbloquear | Desbloquear |
Inteligencia de amenazas
Interés: 🔍Actores activos: 🔍
Grupos APT activos: 🔍
Contramedidas
Recomendación: ActualizaciónEstado: 🔍
Hora de 0 días: 🔍
Actualización: Kernel 6.1.11
Parche: 96aaaf8666010a39430cecf8a65c7ce2908a030f/edb5d0cf5525357652aff6eacd9850b8ced07143
Línea de tiempo
2024-08-21 🔍2025-03-27 🔍
2025-03-27 🔍
2025-12-07 🔍
Fuentes
Proveedor: kernel.orgAviso: git.kernel.org
Estado: Confirmado
CVE: CVE-2023-52934 (🔍)
GCVE (CVE): GCVE-0-2023-52934
GCVE (VulDB): GCVE-100-301714
CERT Bund: WID-SEC-2025-0649 - Linux Kernel: Mehrere Schwachstellen
Artículo
Fecha de creación: 2025-03-27 17:59Actualizado: 2025-12-07 01:44
Cambios: 2025-03-27 17:59 (57), 2025-08-24 08:06 (7), 2025-10-28 21:06 (11), 2025-12-07 01:44 (1)
Completo: 🔍
Cache ID: 216::103
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Sin comentarios aún. Idiomas: es + pt + en.
Por favor, inicie sesión para comentar.