The Zephyr ext2 filesystem driver fails to validate the s_log_block_size field of the on-disk superblock when mounting an ext2 filesystem. The ext2_verify_disk_superblock() function checks several fields but does not bound s_log_block_size. The block size is computed as 1024 shifted left by s_log_block_size, which can overflow or produce a block size larger than the configured maximum. This oversized block size is used to initialize a memory slab without verifying it fits the backing buffer, causing the slab to overflow a static buffer. When the filesystem mount reads block data into this slab, it results in an out-of-bounds write to adjacent static memory. Because the ext2 driver runs in kernel mode, this memory corruption can lead to denial of service or code execution. The vulnerability is exploitable by presenting a crafted ext2 image to a device that mounts it, such as a removable storage medium. The fix rejects s_log_block_size values that overflow the shift or produce a block size exceeding the maximum allowed.

An attacker able to supply a crafted ext2 filesystem image to a device running the vulnerable Zephyr ext2 driver can trigger a kernel-mode memory corruption via an out-of-bounds write. This can result in denial of service or potentially arbitrary code execution with kernel privileges. The vulnerability arises from improper validation of the s_log_block_size field leading to buffer overflow during filesystem mounting.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix rejects invalid s_log_block_size values that cause overflow or exceed the maximum block size, preventing the slab overflow. Until an official fix is available, avoid mounting untrusted ext2 filesystem images on affected Zephyr versions.