Linux Kernel hasta 6.1.80/6.6.20/6.7.8 btrfs Filesystem ioctl.c create_snapshot desbordamiento de búfer

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

Resumeninformación

Una vulnerabilidad fue encontrada en Linux Kernel hasta 6.1.80/6.6.20/6.7.8 y clasificada como problemática. Resulta afectada una función desconocida dentro del archivo ioctl.c dentro del componente btrfs Filesystem Handler. La alteración resulta en desbordamiento de búfer. La vulnerabilidad es identificada como CVE-2024-26792. No existe ningún exploit disponible. El mejor modo sugerido para mitigar el problema es actualizar a la última versión.

Detallesinformación

Una vulnerabilidad clasificada como problemática ha sido encontrada en Linux Kernel hasta 6.1.80/6.6.20/6.7.8. La función create_snapshot del archivo ioctl.c del componente btrfs Filesystem Handler es afectada por esta vulnerabilidad. Mediante 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: btrfs: corrige la doble liberación de un dispositivo anónimo después de un error en la creación de la instantánea. Al crear una instantánea podemos hacer una doble liberación de un dispositivo anónimo en caso de que haya un error al realizar la transacción. La segunda liberación puede resultar en la liberación de un número de dispositivo anónimo asignado por algún otro subSYSTEM en el kernel u otro SYSTEM de archivos btrfs. Los pasos que conducen a esto: 1) En ioctl.c:create_snapshot() asignamos un número de dispositivo anónimo y lo asignamos a pendiente_snapshot->anon_dev; 2) Luego llamamos a btrfs_commit_transaction() y terminamos en transaction.c:create_pending_snapshot(); 3) Allí llamamos a btrfs_get_new_fs_root() y le pasamos el número de dispositivo anónimo almacenado en pendiente_snapshot->anon_dev; 4) btrfs_get_new_fs_root() libera ese número de dispositivo anónimo porque btrfs_lookup_fs_root() devolvió una raíz; alguien más ya hizo una búsqueda de la nueva raíz, lo que podría realizar alguna tarea haciendo retroceder la referencia; 5) Después de eso, ocurre algún error en la ruta de confirmación de la transacción, y en ioctl.c:create_snapshot() saltamos a la etiqueta 'fail', y luego liberamos nuevamente el mismo número de dispositivo anónimo, que mientras tanto puede haber sido reasignado en otro lugar, porque pendiente_snapshot->anon_dev todavía tiene el mismo valor que en el paso 1. Recientemente, syzbot se encontró con esto e informó el siguiente seguimiento: ------------[ cortar aquí ]---- -------- ida_free solicitó id=51 que no está asignado. ADVERTENCIA: CPU: 1 PID: 31038 en lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525 Módulos vinculados en: CPU: 1 PID: 31038 Comm: syz-executor.2 No contaminado 6.8.0 -rc4-syzkaller-00410-gc02197fc9076 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525 Código: 10 42 80 3c 28 (...) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 00000000000000033 RCX: 0000000000040000 RDX: ffffc90009a7a000 R SI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: ffff52002b4cdb5 R12: 0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS :0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Rastreo de llamadas: < TAREA> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfs_ transacción_commit+0xf1c/ 0x3740 fs/btrfs/transaction.c:2404 create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs /ioctl.c :1044 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfs_ioctl+0xa74/0xd40 vfs_ioct l fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl .c:871 [en línea] __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857 do_syscall_64+0xfb/0x240 Entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Código: 28 00 00 00 ( ...) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009 417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 00000000000000000 R10: 00000000000000000 R11: 00000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658 Donde recibimos un mensaje explícito donde intentamos liberar un número de dispositivo anónimo que no está asignado actualmente.,---truncado---

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2024-26792. 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.81, 6.6.21 o 6.7.9 elimina esta vulnerabilidad. Aplicando el parche c34adc20b91a/eb3441093aad/c8ab7521665b 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-0773). Once again VulDB remains the best source for vulnerability data.

Afectado

  • Debian Linux
  • Amazon Linux 2
  • Red Hat Enterprise Linux
  • Ubuntu Linux
  • SUSE Linux
  • IBM InfoSphere Guardium
  • Oracle Linux
  • NetApp FAS
  • EMC Avamar
  • Oracle VM
  • NetApp AFF
  • Dell NetWorker
  • IBM Security Guardium
  • RESF Rocky Linux
  • Open Source Linux Kernel
  • SolarWinds Security Event Manager
  • Broadcom Brocade SANnav
  • IBM Business Automation Workflow
  • IBM Spectrum Protect Plus
  • IBM QRadar SIEM
  • Juniper Junos Space
  • IBM DB2
  • IBM Storage Scale System

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: 6.2
VulDB Puntuación meta temporal: 6.1

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

NVD Puntuación base: 7.8
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-415 / 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 6.1.81/6.6.21/6.7.9
Parche: c34adc20b91a/eb3441093aad/c8ab7521665b

Línea de tiempoinformación

2024-02-19 🔍
2024-04-04 +44 días 🔍
2024-04-04 +0 días 🔍
2025-08-04 +486 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2024-26792 (🔍)
GCVE (CVE): GCVE-0-2024-26792
GCVE (VulDB): GCVE-100-259324
CERT Bund: WID-SEC-2024-0773 - Linux Kernel: Mehrere Schwachstellen

Artículoinformación

Fecha de creación: 2024-04-04 14:50
Actualizado: 2025-08-04 00:47
Cambios: 2024-04-04 14:50 (58), 2024-12-20 17:23 (13), 2025-08-04 00:47 (7)
Completo: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Discusión

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

Por favor, inicie sesión para comentar.

Interested in the pricing of exploits?

See the underground prices here!