Summary
The generic ZPL_TABLE hashtable implementation assigns buckets with key % zpl_array_count(h->hashes). If a downstream application inserts attacker-controlled numeric keys directly into this table, an attacker can choose many distinct keys with the same modulo bucket and force long per-bucket chains.
This is an algorithmic-complexity denial-of-service risk for applications that expose the table key to untrusted input. I did not find an in-repository application path that directly accepts untrusted input into this table; this report is about the generic API behavior and downstream risk.
Affected Code
code/header/essentials/collections/hashtable.h
- Function generated by
ZPL_TABLE_DEFINE: <prefix>_find
Relevant behavior:
r.hash_index = key % zpl_array_count(h->hashes);
r.entry_index = h->hashes[r.hash_index];
while (r.entry_index >= 0) {
if (h->entries[r.entry_index].key == key) return r;
r.entry_prev = r.entry_index;
r.entry_index = h->entries[r.entry_index].next;
}
Reproduction Concept
- Instantiate a table with
ZPL_TABLE.
- Initialize it and use a known bucket count, for example by calling
rehash to B.
- Insert many distinct keys of the form
offset + i * B.
- All of these keys map to the same bucket because
(offset + i * B) % B == offset.
- Each insert/lookup in that bucket walks an increasingly long linked chain.
Expected complexity under this pattern:
- Lookup for a colliding absent key:
O(n)
- Insertion of many colliding keys: approximately
O(n^2) total work
Impact
In a service that uses this table with attacker-controlled numeric keys, a single client can cause excessive CPU work by submitting many colliding keys. With enough requests, this can degrade service availability.
Notes
This is not a full-key equality confusion bug: _find compares the complete zpl_u64 key before returning a match. Distinct colliding keys remain distinct entries. The risk is collision-chain amplification caused by predictable modulo bucket assignment.
Summary
The generic
ZPL_TABLEhashtable implementation assigns buckets withkey % zpl_array_count(h->hashes). If a downstream application inserts attacker-controlled numeric keys directly into this table, an attacker can choose many distinct keys with the same modulo bucket and force long per-bucket chains.This is an algorithmic-complexity denial-of-service risk for applications that expose the table key to untrusted input. I did not find an in-repository application path that directly accepts untrusted input into this table; this report is about the generic API behavior and downstream risk.
Affected Code
code/header/essentials/collections/hashtable.hZPL_TABLE_DEFINE:<prefix>_findRelevant behavior:
Reproduction Concept
ZPL_TABLE.rehashtoB.offset + i * B.(offset + i * B) % B == offset.Expected complexity under this pattern:
O(n)O(n^2)total workImpact
In a service that uses this table with attacker-controlled numeric keys, a single client can cause excessive CPU work by submitting many colliding keys. With enough requests, this can degrade service availability.
Notes
This is not a full-key equality confusion bug:
_findcompares the completezpl_u64key before returning a match. Distinct colliding keys remain distinct entries. The risk is collision-chain amplification caused by predictable modulo bucket assignment.