Linux Kernel hasta 6.6.40/6.9.9 lib/xarray.c denegación de servicio

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

Resumeninformación

Se ha identificado una vulnerabilidad clasificada como problemática en Linux Kernel hasta 6.6.40/6.9.9. Está afectada una función desconocida en la librería lib/xarray.c. El manejo da lugar a denegación de servicio. Esta vulnerabilidad se cataloga como CVE-2024-42243. No se encuentra disponible ningún exploit. Se aconseja actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad clasificada como problemática fue encontrada en Linux Kernel hasta 6.6.40/6.9.9. Una función desconocida en la biblioteca lib/xarray.c es afectada por esta vulnerabilidad. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase denegación de servicio. Esto tiene repercusión sobre la la disponibilidad. El resumen de CVE es:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/filemap: hacer que MAX_PAGECACHE_ORDER sea aceptable para xarray Serie de parches "mm/filemap: limitar el tamaño de caché de página al admitido por xarray", v2. Actualmente, xarray no puede admitir un tamaño de caché de página arbitrario. Se pueden encontrar más detalles en la declaración WARN_ON() en xas_split_alloc(). En nuestra prueba cuyo código se adjunta a continuación, presionamos WARN_ON() en el sistema ARM64 donde el tamaño de página base es de 64 KB y el tamaño de página enorme es de 512 MB. El problema se informó hace mucho tiempo y se pueden encontrar algunas discusiones al respecto aquí [1]. [1] https://www.spinics.net/lists/linux-xfs/msg75404.html Para solucionar el problema, debemos ajustar MAX_PAGECACHE_ORDER a uno compatible con xarray y evitar el caché de páginas del tamaño de PMD si es necesario. Los cambios de código los sugiere David Hildenbrand. PATCH[1] ajusta MAX_PAGECACHE_ORDER al soportado por xarray PATCH[2-3] evita el caché de páginas de tamaño PMD en la ruta de lectura anticipada sincrónica PATCH[4] evita el caché de páginas de tamaño PMD para archivos shmem si es necesario Programa de prueba ===== ======= # cat test.c #define _GNU_SOURCE #incluye #incluye #incluye #incluye #incluye #include #include #include #define TEST_XFS_FILENAME "/tmp/data" #define TEST_SHMEM_FILENAME "/dev/shm/data" #define TEST_MEM_SIZE 0x20000000 int main(int argc, char **argv) { const char *nombre de archivo; intfd = 0; vacío *buf = (vacío *)-1, *p; int pgsize = getpagesize(); ret int; if (pgsize != 0x10000) { fprintf(stderr, "se requiere un tamaño de página base de 64 KB\n"); devolver -EPERM; } system("echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled"); sistema("rm -fr /tmp/data"); sistema("rm -fr /dev/shm/data"); sistema("echo 1 > /proc/sys/vm/drop_caches"); /* Abrir archivo xfs o shmem */ filename = TEST_XFS_FILENAME; if (argc > 1 && !strcmp(argv[1], "shmem")) nombre de archivo = TEST_SHMEM_FILENAME; fd = open(nombre de archivo, O_CREAT | O_RDWR | O_TRUNC); if (fd < 0) { fprintf(stderr, "No se puede abrir <%s>\n", nombre de archivo); devolver -EIO; } /* Ampliar tamaño de archivo */ ret = ftruncate(fd, TEST_MEM_SIZE); if (ret) { fprintf(stderr, "Error %d al ftruncate()\n", ret); ir a limpieza; } /* Crear VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (buf == (void *)-1) { fprintf(stderr, "No se puede mmap <%s>\n", nombre de archivo); ir a limpieza; } fprintf(stdout, "búfer asignado en 0x%p\n", buf); ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE); if (ret) { fprintf(stderr, "No se puede madvise(MADV_HUGEPAGE)\n"); ir a limpieza; } /* Completar VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE); if (ret) { fprintf(stderr, "Error %d en madvise(MADV_POPULATE_WRITE)\n", ret); ir a limpieza; } /* Perfora el archivo para aplicar la división xarray */ ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, TEST_MEM_SIZE - pgsize, pgsize); if (ret) fprintf(stderr, "Error %d al fallacate()\n", ret); limpieza: if (buf != (void *)-1) munmap(buf, TEST_MEM_SIZE); si (fd > 0) cerrar(fd); devolver 0; } # gcc test.c -o prueba # cat /proc/1/smaps | grep Tamaño de página de kernel | head -n 1 KernelPageSize: 64 kB # ./test shmem : ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 17 PID: 5253 en lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Módulos vinculados en: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon \ drm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \ virtio_net sha1_ce net_failover failover virtio_console virtio_blk \ dimlib virtio_mmio CPU: 17 PID: 5253 Comm: prueba Kdump: cargado Contaminado: GW 6.10.0-rc5-gavin+ #12 ---truncado---

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2024-42243. Se considera difícil de explotar. Detalles técnicos son conocidos, pero no hay ningún exploit público disponible.

Para el scanner Nessus se dispone de un plugin ID 208423 (SUSE SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:3551-1)), que puede ayudar a determinar la existencia del riesgo analizado.

Una actualización a la versión 6.6.41 o 6.9.10 elimina esta vulnerabilidad. Aplicando el parche a0c42ddd0969/333c5539a31f/099d90642a71 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 Tenable (208423). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

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.0
VulDB Puntuación meta temporal: 4.9

VulDB Puntuación base: 4.6
VulDB Puntuación temporal: 4.4
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: Denegación de servicio
CWE: CWE-770 / CWE-400 / CWE-404
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

Nessus ID: 208423
Nessus Nombre: SUSE SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2024:3551-1)

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 6.6.41/6.9.10
Parche: a0c42ddd0969/333c5539a31f/099d90642a71

Línea de tiempoinformación

2024-07-30 🔍
2024-08-07 +8 días 🔍
2024-08-07 +0 días 🔍
2024-10-09 +63 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2024-42243 (🔍)
GCVE (CVE): GCVE-0-2024-42243
GCVE (VulDB): GCVE-100-273873

Artículoinformación

Fecha de creación: 2024-08-07 18:05
Actualizado: 2024-10-09 23:59
Cambios: 2024-08-07 18:05 (57), 2024-08-09 16:09 (13), 2024-10-09 23:59 (2)
Completo: 🔍
Cache ID: 216::103

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discusión

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

Por favor, inicie sesión para comentar.

◂ AnteriorVisión De ConjuntoPróximo ▸

Might our Artificial Intelligence support you?

Check our Alexa App!