Ticket History #9150: libdb2 does not adequately validate hash metadata

# Mon Nov 04 18:06:31 2024 Val VF <federicovalenso@gmail.com> - Ticket created

Date:	Fri, 1 Nov 2024 12:27:20 +0300
To:	krb5-bugs@mit.edu
From:	"Val VF" <federicovalenso@gmail.com>
Subject:	Tainted array index at plugins/kdb/db2/libdb2/hash/hash.c:__kdb2_hash_open

Download (untitled) / with headers
text/plain 317B

Download (untitled) / with headers
text/html 433B

Good day!

Variable hashp->hdr.ovfl_point was read from file, we should make sure this value is within bounds, because it's used as an array index.

With respect,

Valery Fedorenko

# Mon Nov 04 18:25:36 2024 ghudson@mit.edu (Greg Hudson) - Subject changed from 'Tainted array index at plugins/kdb/db2/libdb2/hash/hash.c:__kdb2_hash_open' to 'libdb2 does not adequately validate hash metadata'

# Mon Nov 04 18:32:23 2024 ghudson@mit.edu (Greg Hudson) - Comments added

Download (untitled) / with headers
text/html 722B

This came in as a series of apparent static analysis reports. A second report noted a second tainting issue in the same function. Everything used in the bpages calculation at line 169 comes from the database file without validation, which means the memset() at line 174 could exceed the bounds of hashp->mapp for a variety of reasons.

This isn't a security issue because KDB metadata is trusted input, and this isn't likely to manifest as a bug because the hash database type isn't used by default (btree is). But since this code appears very lax about validating metadata loaded from the DB file, there could be similar issues in the btree code or elsewhere in the hash code.

# Mon Nov 04 18:32:23 2024 ghudson@mit.edu (Greg Hudson) - Status changed from 'new' to 'open'

# Sat Nov 23 17:01:31 2024 ghudson@mit.edu (Greg Hudson) - Comments added

Download (untitled) / with headers
text/html 236B

Another static analysis result noted that hash_page.c:__split_page() obtains a page at line 410 with __get_page(), which can return NULL, but doesn't check the result and dereferences it unconditionally at line 413.