Linux Kernel hasta 6.9.4 denegación de servicio

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

Resumeninformación

Una vulnerabilidad clasificada como crítica fue encontrada en Linux Kernel hasta 6.9.4. Está afectada una función desconocida. Mediante la manipulación de un input desconocido se causa una vulnerabilidad de clase denegación de servicio. Esta vulnerabilidad se conoce como CVE-2024-38306. No existe ningún exploit disponible. Se recomienda actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad clasificada como crítica ha sido encontrada en Linux Kernel hasta 6.9.4. Una función desconocida 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. CVE resume:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: proteger folio::privado al adjuntar folios de búfer de extensión [ERROR] Desde la versión 6.8, varias personas reportan fallas raras del kernel, el factor común son mensajes de error de estado incorrecto de la página así: ERROR: Estado incorrecto de la página en el proceso kswapd0 pfn:d6e840 página: refcount:0 mapcount:0 mapeo:000000007512f4f2 index:0x2796c2c7c pfn:0xd6e840 aops:btree_aops ino:1 flags: 0x17ffffe0000008(uptodate|node=0|zone= 2 |lastcpupid=0x3fffff) tipo de página: 0xffffffff() raw: 0017ffffe0000008 dead000000000100 dead000000000122 ffff88826d0be4c0 raw: 00000002796c2c7c 0000000000000000 0000 0000ffffffff 0000000000000000 página volcada porque: mapeo no NULL [CAUSA] Commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() para asignar el método luego adjuntar ") cambia la secuencia al asignar un nuevo búfer de extensión. Anteriormente siempre llamábamos a grab_extent_buffer() en mapeo->i_private_lock, para garantizar la seguridad en la modificación en folio::private (que es un puntero al búfer de extensión para el tamaño de sector normal). Esto puede llevar a la siguiente ejecución: el subproceso A está intentando asignar un búfer de extensión en el bytenr X, con 4 páginas de 4K, mientras que el subproceso B está intentando liberar la página en X + 4K (la segunda página del búfer de extensión en X) . Hilo A | Hilo B -----------------------------------+------------ ------------------------- | btree_release_folio() | | Esto es para la página en X + 4K, | | No la página X. | | alloc_extent_buffer() | |- release_extent_buffer() |- filemap_add_folio() para el | | |- atomic_dec_and_test(eb->refs) | página en bytenr X (la primera | | | | página). | | | | Que devolvió -EEXIST. | | | | | | | |- filemap_lock_folio() | | | | Devolvió la primera página bloqueada. | | | | | | | |- grab_extent_buffer() | | | | |- atomic_inc_not_zero() | | | | | Devuelto falso | | | | |- folio_detach_private() | | |- folio_detach_private() para X | |- folio_test_private() | | |- folio_test_private() | Devuelto verdadero | | | Devuelto verdadero |- folio_put() | |- folio_put() Ahora hay dos opciones de venta en el mismo folio en el folio X, lo que provoca un recuento insuficiente del folio X y, finalmente, provoca el error BUG_ON() en la página->mapeo. La condición no es tan fácil de cumplir: - La publicación debe activarse para la página intermedia de un eb. Si la publicación está en la misma primera página de un eb, el bloqueo de página se activaría e impediría la ejecución. - folio_detach_private() tiene una ventana de ejecución muy pequeña. Es solo entre folio_test_private() y folio_clear_private(). Eso es exactamente cuando se usa mapeo->i_private_lock para evitar dicha ejecución, y la confirmación 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() para asignar-luego-adjuntar método") arruinó eso. En ese momento, pensé que el bloqueo de página se activaría ya que filemap_release_folio() también requiere que la página esté bloqueada, pero olvidé que filemap_release_folio() solo bloquea una página, no todas las páginas de un búfer de extensión. [FIX] Mueva todo el código que requiere i_private_lock a adjunto_eb_folio_to_filemap(), para que todo se haga con la protección de bloqueo adecuada. Además, para evitar problemas futuros, agregue un lockdep_assert_locked() adicional para garantizar que mantenemos el bloqueo adecuado. Para el reproductor que puede iniciar la ejecución (tarda unos minutos con el código instrumentado insertando retrasos en alloc_extent_buffer()): #!/bin/sh drop_caches () { while(true); hacer echo 3 > /proc/sys/vm/drop_caches echo 1 > /proc/sys/vm/compact_memory hecho } run_tar () { while(true); hacer para x en `seq 1 80`; hacer tar cf /dev/zero /mnt > /dev/null & hecho esperar hecho } mkfs.btrfs -f -d single -m single ---truncado---

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2024-38306. Se considera difícil de explotar. No se conoce los detalles técnicos ni hay ningún exploit disponible.

Una actualización a la versión 6.9.5 elimina esta vulnerabilidad. Aplicando el parche 952f048eb901/f3a5367c679d 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-2024-1451). VulDB is the best source for vulnerability data and more expert information about this specific topic.

Afectado

  • Debian Linux
  • Amazon Linux 2
  • Red Hat Enterprise Linux
  • Ubuntu Linux
  • SUSE Linux
  • Oracle Linux
  • RESF Rocky Linux
  • Open Source Linux Kernel
  • IBM QRadar SIEM
  • Dell PowerProtect Data Domain
  • Dell PowerProtect Data Domain Management Center
  • Dell PowerProtect Data Domain OS

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: 4.8
VulDB Puntuación meta temporal: 4.6

VulDB Puntuación base: 4.8
VulDB Puntuación temporal: 4.6
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 4.7
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-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

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.9.5
Parche: 952f048eb901/f3a5367c679d

Línea de tiempoinformación

2024-06-24 🔍
2024-06-25 +1 días 🔍
2024-06-25 +0 días 🔍
2026-04-07 +650 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2024-38306 (🔍)
GCVE (CVE): GCVE-0-2024-38306
GCVE (VulDB): GCVE-100-269640
CERT Bund: WID-SEC-2024-1451 - Linux Kernel: Mehrere Schwachstellen

Artículoinformación

Fecha de creación: 2024-06-25 17:11
Actualizado: 2026-04-07 00:28
Cambios: 2024-06-25 17:11 (56), 2025-09-17 18:34 (11), 2026-04-07 00:28 (7)
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 ▸

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!