mahaloz · October 22, 2019 18:31
diff --git a/cvedesc.txt b/cvedesc.txt
 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.
	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.