{"id":"CVE-2026-10645","aliases":["EUVD-2026-38408","GHSA-hwrh-9h3x-vccm","UBUNTU-CVE-2026-10645"],"status":"published","title":"Out-of-bounds read in Zephyr ext2 directory entry traversal from a crafted filesystem image","description":"The Zephyr ext2 filesystem driver (subsys/fs/ext2) trusted the on-disk directory entry fields de_rec_len and de_name_len when walking a directory block. ext2_fetch_direntry() guarded only with de_name_len \u003e EXT2_MAX_FILE_NAME, but de_name_len is a uint8_t and EXT2_MAX_FILE_NAME is 255, so the check is always false; the function then memcpy'd up to 255 name bytes and the lookup/readdir paths advanced traversal by an unvalidated de_rec_len. Each directory block is read into a block_size-sized slab buffer, and block_off can be driven near the block end by preceding entries' rec_len, so the 8-byte header read and the subsequent name memcpy can read up to ~263 bytes past the end of the block buffer into adjacent heap/slab memory. On the readdir path those bytes are returned to the caller in fs_dirent.name, leaking adjacent kernel heap memory; a de_rec_len of 0 also causes a zero-progress infinite loop (denial of service), and the unlink path's memmove(de, next, next_reclen) over unvalidated records is an additional OOB read/write source. The defect is reached by any path-based operation (open, stat, unlink, rename, mkdir) or directory listing on a mounted ext2 volume, so a crafted or corrupted ext2 image on attacker-supplied storage (SD card, USB mass storage, or otherwise mounted image) triggers it. Affected: Zephyr ext2 from its introduction in v3.5.0 through v4.4.0. The fix validates rec_len and name_len in the parser and rejects entries whose header does not fit the remaining block or whose rec_len crosses the block boundary in every traversal caller.","severity":{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00158,"percentile":0.04987,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-125"],"published":"2026-06-22T23:48:11Z","modified":"2026-11-04T04:58:18Z","affected":[{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1","3.1.2-1build1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1build1","3.1.2-1build2"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1build3"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1build3"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1.1","3.1.2-1.1build1"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1.1build1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-4"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"zephyr","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.2-1.1build1","3.1.2-4"]}],"products":[{"vendor":"zephyrproject","product":"zephyr"},{"vendor":"zephyrproject-rtos","product":"zephyr"}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/7cdb534a3c3daeaec18f656953857dcafa33a2bf","tags":["patch","fix"]},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-hwrh-9h3x-vccm","tags":["Exploit","Patch","Vendor Advisory","advisory","report"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/10xxx/CVE-2026-10645.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-10645","tags":["advisory"]},{"url":"https://github.com/zephyrproject-rtos/zephyr","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2026-10645","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-10645","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-10645","title":"Out-of-bounds read in Zephyr ext2 directory entry traversal from a crafted filesystem image","description":"The Zephyr ext2 filesystem driver (subsys/fs/ext2) trusted the on-disk directory entry fields de_rec_len and de_name_len when walking a directory block. ext2_fetch_direntry() guarded only with de_name_len \u003e EXT2_MAX_FILE_NAME, but de_name_len is a uint8_t and EXT2_MAX_FILE_NAME is 255, so the check is always false; the function then memcpy'd up to 255 name bytes and the lookup/readdir paths advanced traversal by an unvalidated de_rec_len. Each directory block is read into a block_size-sized slab buffer, and block_off can be driven near the block end by preceding entries' rec_len, so the 8-byte header read and the subsequent name memcpy can read up to ~263 bytes past the end of the block buffer into adjacent heap/slab memory. On the readdir path those bytes are returned to the caller in fs_dirent.name, leaking adjacent kernel heap memory; a de_rec_len of 0 also causes a zero-progress infinite loop (denial of service), and the unlink path's memmove(de, next, next_reclen) over unvalidated records is an additional OOB read/write source. The defect is reached by any path-based operation (open, stat, unlink, rename, mkdir) or directory listing on a mounted ext2 volume, so a crafted or corrupted ext2 image on attacker-supplied storage (SD card, USB mass storage, or otherwise mounted image) triggers it. Affected: Zephyr ext2 from its introduction in v3.5.0 through v4.4.0. The fix validates rec_len and name_len in the parser and rejects entries whose header does not fit the remaining block or whose rec_len crosses the block boundary in every traversal caller.","status":"published","published":"2026-06-22T23:48:11.747Z","modified":"2026-11-04T04:58:18.458Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-125"],"updated_at":"2026-11-04T05:21:48.223566Z"}],"euvd":[{"id":"EUVD-2026-38408","description":"The Zephyr ext2 filesystem driver (subsys/fs/ext2) trusted the on-disk directory entry fields de_rec_len and de_name_len when walking a directory block. ext2_fetch_direntry() guarded only with de_name_len \u003e EXT2_MAX_FILE_NAME, but de_name_len is a uint8_t and EXT2_MAX_FILE_NAME is 255, so the check is always false; the function then memcpy'd up to 255 name bytes and the lookup/readdir paths advanced traversal by an unvalidated de_rec_len. Each directory block is read into a block_size-sized slab buffer, and block_off can be driven near the block end by preceding entries' rec_len, so the 8-byte header read and the subsequent name memcpy can read up to ~263 bytes past the end of the block buffer into adjacent heap/slab memory. On the readdir path those bytes are returned to the caller in fs_dirent.name, leaking adjacent kernel heap memory; a de_rec_len of 0 also causes a zero-progress infinite loop (denial of service), and the unlink path's memmove(de, next, next_reclen) over unvalidated records is an additional OOB read/write source. The defect is reached by any path-based operation (open, stat, unlink, rename, mkdir) or directory listing on a mounted ext2 volume, so a crafted or corrupted ext2 image on attacker-supplied storage (SD card, USB mass storage, or otherwise mounted image) triggers it. Affected: Zephyr ext2 from its introduction in v3.5.0 through v4.4.0. The fix validates rec_len and name_len in the parser and rejects entries whose header does not fit the remaining block or whose rec_len crosses the block boundary in every traversal caller.","status":"published","published":"2026-06-22T23:48:11Z","modified":"2026-11-04T04:58:18Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H","level":"medium"}],"updated_at":"2026-11-04T07:00:56.720215Z"}],"nvd":[{"id":"CVE-2026-10645","description":"The Zephyr ext2 filesystem driver (subsys/fs/ext2) trusted the on-disk directory entry fields de_rec_len and de_name_len when walking a directory block. ext2_fetch_direntry() guarded only with de_name_len \u003e EXT2_MAX_FILE_NAME, but de_name_len is a uint8_t and EXT2_MAX_FILE_NAME is 255, so the check is always false; the function then memcpy'd up to 255 name bytes and the lookup/readdir paths advanced traversal by an unvalidated de_rec_len. Each directory block is read into a block_size-sized slab buffer, and block_off can be driven near the block end by preceding entries' rec_len, so the 8-byte header read and the subsequent name memcpy can read up to ~263 bytes past the end of the block buffer into adjacent heap/slab memory. On the readdir path those bytes are returned to the caller in fs_dirent.name, leaking adjacent kernel heap memory; a de_rec_len of 0 also causes a zero-progress infinite loop (denial of service), and the unlink path's memmove(de, next, next_reclen) over unvalidated records is an additional OOB read/write source. The defect is reached by any path-based operation (open, stat, unlink, rename, mkdir) or directory listing on a mounted ext2 volume, so a crafted or corrupted ext2 image on attacker-supplied storage (SD card, USB mass storage, or otherwise mounted image) triggers it. Affected: Zephyr ext2 from its introduction in v3.5.0 through v4.4.0. The fix validates rec_len and name_len in the parser and rejects entries whose header does not fit the remaining block or whose rec_len crosses the block boundary in every traversal caller.","status":"published","published":"2026-06-23T01:16:26.607Z","modified":"2026-11-04T05:18:23.483Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H","level":"medium","assessor":"secondary"},{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H","level":"medium","assessor":"primary"}],"cwes":["CWE-125"],"updated_at":"2026-11-04T06:53:16.37612Z"}],"osv":[{"id":"CVE-2026-10645","title":"Out-of-bounds read in Zephyr ext2 directory entry traversal from a crafted filesystem image","description":"The Zephyr ext2 filesystem driver (subsys/fs/ext2) trusted the on-disk directory entry fields de_rec_len and de_name_len when walking a directory block. ext2_fetch_direntry() guarded only with de_name_len \u003e EXT2_MAX_FILE_NAME, but de_name_len is a uint8_t and EXT2_MAX_FILE_NAME is 255, so the check is always false; the function then memcpy'd up to 255 name bytes and the lookup/readdir paths advanced traversal by an unvalidated de_rec_len. Each directory block is read into a block_size-sized slab buffer, and block_off can be driven near the block end by preceding entries' rec_len, so the 8-byte header read and the subsequent name memcpy can read up to ~263 bytes past the end of the block buffer into adjacent heap/slab memory. On the readdir path those bytes are returned to the caller in fs_dirent.name, leaking adjacent kernel heap memory; a de_rec_len of 0 also causes a zero-progress infinite loop (denial of service), and the unlink path's memmove(de, next, next_reclen) over unvalidated records is an additional OOB read/write source. The defect is reached by any path-based operation (open, stat, unlink, rename, mkdir) or directory listing on a mounted ext2 volume, so a crafted or corrupted ext2 image on attacker-supplied storage (SD card, USB mass storage, or otherwise mounted image) triggers it. Affected: Zephyr ext2 from its introduction in v3.5.0 through v4.4.0. The fix validates rec_len and name_len in the parser and rejects entries whose header does not fit the remaining block or whose rec_len crosses the block boundary in every traversal caller.","status":"published","published":"2026-06-22T23:48:11.747Z","modified":"2026-11-05T08:04:00.097920929Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H","level":"medium"}],"cwes":["CWE-125"],"updated_at":"2026-11-05T09:08:14.330889Z"},{"id":"UBUNTU-CVE-2026-10645","description":"The Zephyr ext2 filesystem driver (subsys/fs/ext2) trusted the on-disk directory entry fields de_rec_len and de_name_len when walking a directory block. ext2_fetch_direntry() guarded only with de_name_len \u003e EXT2_MAX_FILE_NAME, but de_name_len is a uint8_t and EXT2_MAX_FILE_NAME is 255, so the check is always false; the function then memcpy'd up to 255 name bytes and the lookup/readdir paths advanced traversal by an unvalidated de_rec_len. Each directory block is read into a block_size-sized slab buffer, and block_off can be driven near the block end by preceding entries' rec_len, so the 8-byte header read and the subsequent name memcpy can read up to ~263 bytes past the end of the block buffer into adjacent heap/slab memory. On the readdir path those bytes are returned to the caller in fs_dirent.name, leaking adjacent kernel heap memory; a de_rec_len of 0 also causes a zero-progress infinite loop (denial of service), and the unlink path's memmove(de, next, next_reclen) over unvalidated records is an additional OOB read/write source. The defect is reached by any path-based operation (open, stat, unlink, rename, mkdir) or directory listing on a mounted ext2 volume, so a crafted or corrupted ext2 image on attacker-supplied storage (SD card, USB mass storage, or otherwise mounted image) triggers it. Affected: Zephyr ext2 from its introduction in v3.5.0 through v4.4.0. The fix validates rec_len and name_len in the parser and rejects entries whose header does not fit the remaining block or whose rec_len crosses the block boundary in every traversal caller.","status":"published","published":"2026-06-23T01:16:00Z","modified":"2026-10-17T12:58:00.662885575Z","cvss":[{"version":"3.1","score":4.9,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H","level":"medium"},{"version":"3.1","score":5.5,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T16:55:59.130573Z"}]}}