dbus-hash: Fix a potential shift by a negative integer

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 approaching 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
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99641
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Change-Id: Iac3047fc0bff11b3d08c2938c0fda292bddb1466

diff --git a/dbus/dbus-hash.c b/dbus/dbus-hash.c
index 8f7d04bbf17a9e7c60c9c47b888d215c6ae48064..1a66705684c0b60c1a5c775ed9cb051a38bebd06 100644 (file)
--- 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);