Skip to content

Instantly share code, notes, and snippets.

@deephooloovoo
Last active October 24, 2019 15:15
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save deephooloovoo/d91b81a1674b4750e662dfae93804d75 to your computer and use it in GitHub Desktop.
Save deephooloovoo/d91b81a1674b4750e662dfae93804d75 to your computer and use it in GitHub Desktop.
Description of CVE-2019-13103 through CVE-2019-13106
Found by Paul Emge and Zion Basque at ForAllSecure
CVE-2019-13103:
There is a stack overflow when reading a DOS partition table which refers to itself. This causes 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. On QEMU's vexpress-a15 board, the CPU returns to 0 but continues executing NOPs until it hits data and executes it. By analyzing the code, it appears as if it affects all versions of u-boot in the archives.
CVE-2019-13104:
At 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.
CVE-2019-13105:
If there is an invalid/out-of bounds block number, ext_cache_read doesn't set the freed cache->buf to 0, which results in a double free in ext_cache_ini. This affects versions 2019.07-rc1 through 2019.07-rc4.
CVE-2019-13106:
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment