CVE-2026-13215

{"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\u00famero m\u00e1gico, la revisi\u00f3n, el tama\u00f1o de los inodos y los recuentos de grupos, pero nunca limita s_log_block_size. Tras una verificaci\u00f3n 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\u00f1o de bloque mucho mayor que CONFIG_EXT2_MAX_BLOCK_SIZE.\n\nEse tama\u00f1o 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\u00fafer est\u00e1tico fijo __ext2_block_memory_buffer, cuyo tama\u00f1o 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\u00fafer, y el envoltorio ext2 descarta su valor de retorno, por lo que el slab se dispone m\u00e1s all\u00e1 del final del b\u00fafer est\u00e1tico. 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\u00edmites en memoria est\u00e1tica adyacente en la primera lectura de bloque.\n\nLa ruta completa est\u00e1 limitada \u00fanicamente por los datos le\u00eddos 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\u00edble 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\u00f3n de memoria en modo supervisor, con un impacto que va desde la denegaci\u00f3n de servicio hasta la posible ejecuci\u00f3n de c\u00f3digo.\n\nLa soluci\u00f3n rechaza los valores de s_log_block_size que desbordan el desplazamiento (mayores que 11) o que producen un tama\u00f1o de bloque que excede CONFIG_EXT2_MAX_BLOCK_SIZE, por lo que el slab de bloques ya no puede inicializarse con un tama\u00f1o mayor que su b\u00fafer de respaldo."}], "lastModified": "2026-09-28T23:10:00.143", "sourceIdentifier": "vulnerabilities@zephyrproject.org"}