GHSA-j52j-gfj9-rwjm: Zephyr ext2 mount: unvalidated superblock block size causes out-of-bounds write from a crafted filesystem image

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

That block size is then passed to kmemslabinit() by ext2initblocksslab() to carve CONFIGEXT2MAXBLOCKCOUNT blocks out of the fixed static buffer ext2blockmemorybuffer, whose size is CONFIGEXT2MAXBLOCKCOUNT CONFIGEXT2MAXBLOCKSIZE. kmemslabinit() 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->blocksize 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 slogblocksize values that overflow the shift (greater than 11) or that produce a block size exceeding CONFIGEXT2MAXBLOCKSIZE, so the block slab can no longer be initialized larger than its backing buffer.