From 19bc3b4ca052e3c28ca6d5ad85d23f11ce0f3e9e Mon Sep 17 00:00:00 2001 From: Philip Withnall Date: Thu, 2 Feb 2017 10:14:55 +0000 Subject: [PATCH] dbus-hash: Fix a potential shift by a negative integer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As a hash table becomes unbelievably large and full, the down_shift tends towards 0. The overflow detection code in rebuild_table() does not prevent down_shift becoming negative, which then causes undefined behaviour in RANDOM_INDEX for int-keyed tables. Note that this can only happen with approachint INT_MAX entries in the hash table, at which point we’ve almost certainly hit OOM somewhere, so this is vanishingly unlikely to happen. This is why I can’t add a test for the bug. As always, thanks to Coverity. Coverity ID: 54682 https://bugs.freedesktop.org/show_bug.cgi?id=99641 --- dbus/dbus-hash.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dbus/dbus-hash.c b/dbus/dbus-hash.c index 115a81c..ddc17fd 100644 --- a/dbus/dbus-hash.c +++ b/dbus/dbus-hash.c @@ -941,7 +941,7 @@ rebuild_table (DBusHashTable *table) { /* overflow paranoia */ if (table->n_buckets < _DBUS_INT_MAX / 4 && - table->down_shift >= 0) + table->down_shift >= 2) new_buckets = table->n_buckets * 4; else return; /* can't grow anymore */ @@ -993,6 +993,7 @@ rebuild_table (DBusHashTable *table) _dbus_assert (table->lo_rebuild_size >= 0); _dbus_assert (table->hi_rebuild_size > table->lo_rebuild_size); + _dbus_assert (table->down_shift >= 0); _dbus_assert (table->mask != 0); /* the mask is essentially the max index */ _dbus_assert (table->mask < table->n_buckets); -- 2.9.3