Due to the nature of finding these bugs, which was some time ago, I only have the notes of finding these bugs with Paul Emge while we were interns at @ForAllSecure.
All of the CVEs below were obtained using the Mayhem Fuzzer from ForAllSecure
along with some easy harnessing. For the most part, you can run Uboot in it’s
sandbox mode and submit Filesystems for it to be parsed. Using Mayhem, you can
use a normal
ext4 file system as the seed and let it mutate from there.
There is a stack overflow when reading a DOS partition table which refers to itself.
part_get_info_extended to call itself repeatedly with the same arguments,
causing unbounded stack growth. In the sandbox configuration, this results in a segfault.
vexpress-a15 board, the CPU returns to 0 but continues executing NOPs until
it hits data and executes it.
ext4fs.c:74 it is possible for
len to underflow while listing files in a crafted
filesystem. If this happens, eventually there is a memcpy with a negative (so effectively infinite)
length. This causes all of memory to be overwritten until, on the sandbox, it segfaults.
On a real platform, I’m not sure what would happen, but there’s definitely memory corruption.
This affects versions 2016.11-rc1 through 2019.07-rc4.
If there is an invalid/out-of bounds block number,
ext_cache_read doesn’t set the freed
to 0, which results in a double free in
The ext4 code can overwrite portions of the stack with 0s in the
ext4fs_read_file function, while
listing files in an untrusted filesystem. The bug occurs when a filename (or potentially some other
structure) is located across a block boundary. The number of 0s written to the stack is controllable
by changing the position of the filename. The bug could easily give complete control of the CPU,
which would defeat verified boot. This affects versions 2016.09 through 2019.07-rc4.
As stated earlier, this bug would have been impossible without Paul Emge and the amazing team at ForAllSecure who developed the Mayhem system.