Linux Kernel hasta 5.10.36/5.11.20/5.12.3 en SLUB memcontrol rcu_read_lock desbordamiento de búfer

CVSS Puntuación meta temporalPrecio actual del exploit (≈)Puntuación de interés CTI
5.4$0-$5k0.00

Resumeninformación

Se ha encontrado una vulnerabilidad clasificada como problemática en Linux Kernel hasta 5.10.36/5.11.20/5.12.3 en SLUB. Está afectada una función desconocida en el componente memcontrol. Mediante la manipulación de un input desconocido se causa una vulnerabilidad de clase desbordamiento de búfer. Esta vulnerabilidad se cataloga como CVE-2021-47011. No existe ningún exploit disponible. Se aconseja actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad clasificada como problemática ha sido encontrada en Linux Kernel hasta 5.10.36/5.11.20/5.12.3 en SLUB (Operating System). La función rcu_read_lock del componente memcontrol es afectada por esta vulnerabilidad. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase desbordamiento de búfer. 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: memcontrol: slab: fix obtener una referencia a una serie de parches de liberación de memcg "Utilice las API de obj_cgroup para cargar páginas kmem", v5. Desde que se aplicó la serie de Roman "El nuevo controlador de memoria losa de cgroup". Todos los objetos de losa se cargan con las nuevas API de obj_cgroup. Las nuevas API introducen una estructura obj_cgroup para cargar objetos de losa. Evita que los objetos de larga duración fijen el grupo de memoria original en la memoria. Pero todavía hay algunos objetos de esquina (por ejemplo, asignaciones mayores que la página de pedido 1 en SLUB) que no se cargan con las nuevas API. Esos objetos (incluidas las páginas que se asignan directamente desde el asignador de amigos) se cargan como páginas kmem que aún contienen una referencia al grupo de memoria. Por ejemplo, sabemos que la pila del kernel se carga como páginas kmem porque el tamaño de la pila del kernel puede ser mayor que 2 páginas (por ejemplo, 16 KB en x86_64 o arm64). Si creamos un subproceso (supongamos que la pila de subprocesos se carga en el grupo c de memoria A) y luego lo movemos del grupo c de memoria A al grupo c de memoria B. Porque la pila del núcleo del subproceso contiene una referencia al grupo c de memoria A. El hilo puede anclar la memoria cgroup A en la memoria incluso si eliminamos el cgroup A. Si queremos ver este escenario usando el siguiente script. Podemos ver que el sistema ha agregado 500 cgroups moribundos (esto no es un problema del mundo real, solo un script para mostrar que los kmallocs grandes se cargan como páginas kmem que pueden fijar el cgroup de memoria en la memoria). #!/bin/bash cat /proc/cgroups | grep memoria cd /sys/fs/cgroup/memory echo 1 > memoria.move_charge_at_immigrate para i en el rango{1..500} hacer mkdir kmem_test echo $$ > kmem_test/cgroup.procs sleep 3600 & echo $$ > cgroup.procs echo `cat kmem_test/cgroup.procs` > cgroup.procs rmdir kmem_test hecho cat /proc/cgroups | grep memoria Este conjunto de parches tiene como objetivo hacer que esas páginas kmem eliminen la referencia a la memoria cgroup mediante el uso de las API de obj_cgroup. Finalmente, podemos ver que el número de cgroups moribundos no aumentará si ejecutamos el script de prueba anterior. Este parche (de 7): rcu_read_lock/unlock solo puede garantizar que el memcg no se libere, pero no puede garantizar el éxito de css_get (que está en refill_stock cuando se cambia el memcg en caché) a memcg. rcu_read_lock() memcg = obj_cgroup_memcg(old) __memcg_kmem_uncharge(memcg) refill_stock(memcg) if (stock->cached != memcg) // css_get puede cambiar el contador de referencia de 0 a 1. css_get(&memcg->css) rcu_read_unlock( ) Esta solución es muy parecida a el commit: eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge") Solucione este problema manteniendo una referencia al memcg que se pasa a __memcg_kmem_uncharge() antes de llamar a __memcg_kmem_uncharge().

La vulnerabilidad fue publicada el 2024-02-28 (confirmado). El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2021-47011. Hay detalles técnicos conocidos, pero no se dispone de un exploit.

Una actualización a la versión 5.10.37, 5.11.21, 5.12.4 o 5.13 elimina esta vulnerabilidad. Aplicando el parche 31df8bc4d3fe/89b1ed358e01/c3ae6a3f3ca4/9f38f03ae8d5 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.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Productoinformación

Escribe

Proveedor

Nombre

Versión

Licencia

Sitio web

CPE 2.3información

CPE 2.2información

CVSSv4información

VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CVSSv3información

VulDB Puntuación meta base: 5.5
VulDB Puntuación meta temporal: 5.4

VulDB Puntuación base: 5.5
VulDB Puntuación temporal: 5.3
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 5.5
NVD Vector: 🔍

CVSSv2información

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplejidadAutenticaciónConfidencialidadIntegridadDisponibilidad
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear

VulDB Puntuación base: 🔍
VulDB Puntuación temporal: 🔍
VulDB Confiabilidad: 🔍

Explotacióninformación

Clase: Desbordamiento de búfer
CWE: CWE-416 / CWE-119
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-DayDesbloquearDesbloquearDesbloquearDesbloquear
HoyDesbloquearDesbloquearDesbloquearDesbloquear

Inteligencia de amenazasinformación

Interés: 🔍
Actores activos: 🔍
Grupos APT activos: 🔍

Contramedidasinformación

Recomendación: Actualización
Estado: 🔍

Hora de 0 días: 🔍

Actualización: Kernel 5.10.37/5.11.21/5.12.4/5.13
Parche: 31df8bc4d3fe/89b1ed358e01/c3ae6a3f3ca4/9f38f03ae8d5

Línea de tiempoinformación

2024-02-27 🔍
2024-02-28 +1 días 🔍
2024-02-28 +0 días 🔍
2025-01-08 +315 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2021-47011 (🔍)
GCVE (CVE): GCVE-0-2021-47011
GCVE (VulDB): GCVE-100-255048

Artículoinformación

Fecha de creación: 2024-02-28 10:59
Actualizado: 2025-01-08 23:49
Cambios: 2024-02-28 10:59 (44), 2025-01-08 23:49 (26)
Completo: 🔍
Cache ID: 216::103

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Discusión

Sin comentarios aún. Idiomas: es + pt + en.

Por favor, inicie sesión para comentar.

◂ AnteriorVisión De ConjuntoPróximo ▸

Want to know what is going to be exploited?

We predict KEV entries!