« Volver al listado

CVE-2026-13215

Estado: Pendiente de análisisMedia (6.8)—

The Zephyr ext2 filesystem driver fails to validate the s_log_block_size field of the on-disk superblock when mounting a filesystem. ext2_verify_disk_superblock() in subsys/fs/ext2/ext2_impl.c checks the magic number, revision, inode size and group counts, but never bounds s_log_block_size. On a successful verify, subsys/fs/ext2/ext2_ops.c computes fs->block_size = 1024 << superblock.s_log_block_size from this attacker-controlled uint32_t, so a crafted value either overflows the shift (undefined behaviour) or yields a block size far larger than CONFIG_EXT2_MAX_BLOCK_SIZE.

That block size is then passed to k_mem_slab_init() by ext2_init_blocks_slab() to carve CONFIG_EXT2_MAX_BLOCK_COUNT blocks out of the fixed static buffer __ext2_block_memory_buffer, whose size is CONFIG_EXT2_MAX_BLOCK_COUNT * CONFIG_EXT2_MAX_BLOCK_SIZE. k_mem_slab_init() does not verify that the requested blocks fit the buffer, and the ext2 wrapper discards its return value, so the slab is laid out past the end of the static buffer.

Leer descripción completaMostrar menos

The mount immediately reads block-group, bitmap and inode blocks of fs->block_size bytes each into these slab blocks, producing an out-of-bounds write into adjacent static memory on the first block read.

The entire path is gated only by data read from the mounted image, making this reachable by any attacker who can present a crafted ext2 image to a device that mounts it (for example a removable SD card or storage medium). Because the ext2 driver runs in kernel mode, supplying image bytes yields a supervisor-mode memory-corruption primitive, with impact ranging from denial of service to potential code execution.

The fix rejects s_log_block_size values that overflow the shift (greater than 11) or that produce a block size exceeding CONFIG_EXT2_MAX_BLOCK_SIZE, so the block slab can no longer be initialized larger than its backing buffer.

CVSS

Probabilidad de explotación (EPSS)

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

Tecnologías afectadas (1)

⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.

Zephyr — Ext2 Filesystem DriverAI

CWE

Referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2026-13215",
  "cveTags": [],
  "metrics": {
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-13215",
          "role": "CISA Coordinator",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "version": "2.0.3",
          "timestamp": "2026-08-25T15:14:52.214804Z"
        }
      }
    ],
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "vulnerabilities@zephyrproject.org",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 6.8,
          "attackVector": "PHYSICAL",
          "baseSeverity": "MEDIUM",
          "vectorString": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.9,
        "exploitabilityScore": 0.9
      }
    ]
  },
  "affected": [
    {
      "source": "vulnerabilities@zephyrproject.org",
      "affectedData": [
        {
          "vendor": "zephyrproject",
          "product": "zephyr",
          "versions": [
            {
              "status": "affected",
              "version": "3.5.0",
              "lessThan": "4.4.2",
              "versionType": "semver"
            }
          ],
          "packageName": "zephyr",
          "programFiles": [
            "subsys/fs/ext2/ext2_impl.c"
          ],
          "collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
          "defaultStatus": "unaffected"
        }
      ]
    }
  ],
  "published": "2026-08-25T05:17:20.187",
  "references": [
    {
      "url": "https://github.com/zephyrproject-rtos/zephyr/commit/f270f4bd0e59585da31e1fbaa79c5abf73f1364b",
      "source": "vulnerabilities@zephyrproject.org"
    },
    {
      "url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j52j-gfj9-rwjm",
      "source": "vulnerabilities@zephyrproject.org"
    }
  ],
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "type": "Secondary",
      "source": "vulnerabilities@zephyrproject.org",
      "description": [
        {
          "lang": "en",
          "value": "CWE-787"
        }
      ]
    }
  ],
  "descriptions": [
    {
      "lang": "en",
      "value": "The Zephyr ext2 filesystem driver fails to validate the s_log_block_size field of the on-disk superblock when mounting a filesystem. ext2_verify_disk_superblock() in subsys/fs/ext2/ext2_impl.c checks the magic number, revision, inode size and group counts, but never bounds s_log_block_size. On a successful verify, subsys/fs/ext2/ext2_ops.c computes fs->block_size = 1024 << superblock.s_log_block_size from this attacker-controlled uint32_t, so a crafted value either overflows the shift (undefined behaviour) or yields a block size far larger than CONFIG_EXT2_MAX_BLOCK_SIZE.\n\nThat block size is then passed to k_mem_slab_init() by ext2_init_blocks_slab() to carve CONFIG_EXT2_MAX_BLOCK_COUNT blocks out of the fixed static buffer __ext2_block_memory_buffer, whose size is CONFIG_EXT2_MAX_BLOCK_COUNT * CONFIG_EXT2_MAX_BLOCK_SIZE. k_mem_slab_init() does not verify that the requested blocks fit the buffer, and the ext2 wrapper discards its return value, so the slab is laid out past the end of the static buffer. The mount immediately reads block-group, bitmap and inode blocks of fs->block_size bytes each into these slab blocks, producing an out-of-bounds write into adjacent static memory on the first block read.\n\nThe entire path is gated only by data read from the mounted image, making this reachable by any attacker who can present a crafted ext2 image to a device that mounts it (for example a removable SD card or storage medium). Because the ext2 driver runs in kernel mode, supplying image bytes yields a supervisor-mode memory-corruption primitive, with impact ranging from denial of service to potential code execution.\n\nThe fix rejects s_log_block_size values that overflow the shift (greater than 11) or that produce a block size exceeding CONFIG_EXT2_MAX_BLOCK_SIZE, so the block slab can no longer be initialized larger than its backing buffer."
    },
    {
      "lang": "es",
      "value": "El controlador del sistema de archivos ext2 de Zephyr no valida el campo s_log_block_size del superbloque en disco al montar un sistema de archivos. ext2_verify_disk_superblock() en subsys/fs/ext2/ext2_impl.c verifica el número mágico, la revisión, el tamaño de los inodos y los recuentos de grupos, pero nunca limita s_log_block_size. Tras una verificación exitosa, subsys/fs/ext2/ext2_ops.c calcula fs -> block_size = 1024 << superblock.s_log_block_size a partir de este uint32_t controlado por el atacante, por lo que un valor manipulado o bien desborda el desplazamiento (comportamiento indefinido) o produce un tamaño de bloque mucho mayor que CONFIG_EXT2_MAX_BLOCK_SIZE.\n\nEse tamaño de bloque se pasa entonces a k_mem_slab_init() por ext2_init_blocks_slab() para tallar CONFIG_EXT2_MAX_BLOCK_COUNT bloques del búfer estático fijo __ext2_block_memory_buffer, cuyo tamaño es CONFIG_EXT2_MAX_BLOCK_COUNT * CONFIG_EXT2_MAX_BLOCK_SIZE. k_mem_slab_init() no verifica que los bloques solicitados quepan en el búfer, y el envoltorio ext2 descarta su valor de retorno, por lo que el slab se dispone más allá del final del búfer estático. El montaje lee inmediatamente bloques de grupo de bloques, de mapa de bits y de inodos de fs -> block_size bytes cada uno en estos bloques de slab, produciendo una escritura fuera de límites en memoria estática adyacente en la primera lectura de bloque.\n\nLa ruta completa está limitada únicamente por los datos leídos de la imagen montada, haciendo esto alcanzable por cualquier atacante que pueda presentar una imagen ext2 manipulada a un dispositivo que la monte (por ejemplo, una tarjeta SD extraíble o un medio de almacenamiento). Debido a que el controlador ext2 se ejecuta en modo kernel, el suministro de bytes de imagen produce una primitiva de corrupción de memoria en modo supervisor, con un impacto que va desde la denegación de servicio hasta la posible ejecución de código.\n\nLa solución rechaza los valores de s_log_block_size que desbordan el desplazamiento (mayores que 11) o que producen un tamaño de bloque que excede CONFIG_EXT2_MAX_BLOCK_SIZE, por lo que el slab de bloques ya no puede inicializarse con un tamaño mayor que su búfer de respaldo."
    }
  ],
  "lastModified": "2026-09-28T23:10:00.143",
  "sourceIdentifier": "vulnerabilities@zephyrproject.org"
}