Software vulnerabilities detected during code analysis with ESBMC-WR tool

[janislley]

Hello,

Two potential software vulnerabilities were found in the code. To identify this kind of vulnerabilities I used ESBMC-WR tool: https://github.com/thalestas/esbmc-wr We detect it during code exploitation for RUFUS tool. A bug was reported at this time and the developer of RUFUS tool requested to solve this potential issue directly here in mainline code.

Bug reported at RUFUS repository code: pbatard/rufus#1856

More about the tool: https://arxiv.org/pdf/2102.02368.pdf

Expected behavior:

Our main objective was to check memory safety properties (e.g., pointer dereference and memory leaks) while performing the verification code.

Please, check the logs of analysis:

Issue 1 [FILE] src/ext2fs/hashmap.c https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs/hashmap.c#n52

State 4 file hashmap.c line 51 function ext2fs_hashmap_add thread 0 Violated property: file hashmap.c line 51 function ext2fs_hashmap_add division by zero h->size != 0

Issue 2 [FILE] src/ext2fs/hashmap.c https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs/hashmap.c#n103

State 8 file hashmap.c line 99 function ext2fs_hashmap_free thread 0 Violated property: file hashmap.c line 99 function ext2fs_hashmap_free dereference failure: invalid pointer

[tytso]

Can you provide a program which demonstrates how these problems would be demonstrated in real life (in particular for issue #2)?

[janislley]

Hello @tytso Sorry for long delay.

#1 issue : https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs/hashmap.c#n52 uint32_t hash = h->hash(key, key_len) % h->size;

we have a possible vulnerability here caused due division by zero.

#2 issue : https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs/hashmap.c#n103

for (i = 0; i < h->size; ++i) {
	struct ext2fs_hashmap_entry *it = h->entries[i];
	while (it) {
		struct ext2fs_hashmap_entry *tmp = it->next;
		if (h->free)
			h->free(it->data);
		free(it);

It seems to be a false positive. "it pointer" is freed. Please, confirm if there is something missing.

BR.

[tytso]

To be honest, both look bogus. Sure, if you create a hashmap with size 0, this might cause a program to crash. But that's an application level bug. Calling it a vulnerability seems to be a huge stretch.

As for the second one, you're the one who claimed there was a "vulnerability" and it is your tool which claimed there was something wrong. It seems it's up to you to give me a program which can actually result in a invalid pointer derference. Preferable with a call stack which shows how this leads to a problem.

If you can't, then maybe your tool is bogus?

[janislley]

Close the issue as no update for a long time.