CVE-2026-102554

CompactHashMap/CompactHashSet/MapMakerInternalMap native deserialization triggers uncontrolled memory allocation

Summary

CompactHashMap, CompactHashSet, and MapMakerInternalMap implement readObject(ObjectInputStream) by reading an attacker-controlled elementCount or initialCapacity from the stream. On the very first insertion during or after deserialization (for the CompactHash* collections, inside allocArrays()) or immediately during deserialization (for MapMakerInternalMap), the implementation eagerly allocates arrays sized to that full, unvalidated value (up to CompactHashing.MAX_SIZE = 2^30-1, ~1.07 billion, for example) before the rest of the stream's actual content has been consumed. A 72-byte malicious serialized stream containing a single tiny element can force a multi-gigabyte allocation and crash a JVM with OutOfMemoryError, dynamically confirmed against the current release.

Details

CompactHashMap.readObject() (guava/src/com/google/common/collect/CompactHashMap.java):

private void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {
  stream.defaultReadObject();
  int elementCount = stream.readInt();
  if (elementCount < 0) {
    throw new InvalidObjectException("Invalid size: " + elementCount);
  }
  init(elementCount);
  for (int i = 0; i < elementCount; i++) {
    K key = (K) stream.readObject();
    V value = (V) stream.readObject();
    put(key, value);
  }
}

elementCount is only checked for being non-negative; there is no upper bound and no relationship enforced between the declared count and how much data actually follows in the stream. init(elementCount) (line 251) just stores the value (clamped to [1, CompactHashing.MAX_SIZE], i.e. up to 2^30-1):

void init(int expectedSize) {
  Preconditions.checkArgument(expectedSize >= 0, "Expected size must be >= 0");
  this.metadata = Ints.constrainToRange(expectedSize, 1, CompactHashing.MAX_SIZE);
}

The real allocation is deferred to allocArrays(), which fires lazily on the first put() call — i.e. after only one key/value pair has actually been read off the wire:

int allocArrays() {
  ...
  int expectedSize = metadata;
  int buckets = CompactHashing.tableSize(expectedSize);
  this.table = CompactHashing.createTable(buckets);
  setHashTableMask(buckets - 1);
  this.entries = new int[expectedSize];
  this.keys = new Object[expectedSize];
  this.values = new Object[expectedSize];
  return expectedSize;
}

With expectedSize near CompactHashing.MAX_SIZE (2^30-1), this single call allocates a hash table plus three expectedSize-length arrays — multiple gigabytes — triggered by a stream that has, at that point, only supplied one small real element. CompactHashSet.readObject()/allocArrays() have the identical shape. CompactLinkedHashMap/CompactLinkedHashSet extend these classes and inherit the same unguarded path.

The problem with MapMakerInternalMap is similar, with a size read from the serialized data and stored in a MapMaker instance for later user during deserialization, when the MapMaker is passed back to MapMakerInternalMap and segments are allocated by calling newSegment, whose implementations…

Root has patched CVE-2026-102554 in the com.google.guava:guava package for Root:Maven. Multiple fixed versions available.

Allocation of resources without limits or throttling (CWE-770) during Java object deserialization in Google Guava versions 4.0 through 33.7.1 allows an attacker to cause a Denial of Service via OutOfMemoryError. When deserializing CompactHashMap, CompactHashSet, or MapMakerInternalMap instances, Guava eagerly allocates an array based on a caller-specified size parameter without throttling, permitting memory exhaustion from crafted serialization streams.

Allocation of resources without limits or throttling (CWE-770) during Java object deserialization in Google Guava versions 4.0 through 33.7.1 allows an attacker to cause a Denial of Service via OutOfMemoryError. When deserializing CompactHashMap, CompactHashSet, or MapMakerInternalMap instances, Guava eagerly allocates an array based on a caller-specified size parameter without throttling, permitting memory exhaustion from crafted serialization streams.

Allocation of resources without limits or throttling (CWE-770) during Java object deserialization in Google Guava versions 4.0 through 33.7.1 allows an attacker to cause a Denial of Service via OutOfMemoryError. When deserializing CompactHashMap, CompactHashSet, or MapMakerInternalMap instances, Guava eagerly allocates an array based on a caller-specified size parameter without throttling, permitting memory exhaustion from crafted serialization streams.

These are all security issues fixed in the guava-33.7.2-1.1 package on the GA media of openSUSE Tumbleweed.

This update for guava fixes the following issue:

• CVE-2026-102554: Allocation of resources without limits or throttling (CWE-770) during Java object deserialization allows an attacker to cause a Denial of Service via OutOfMemoryError (bsc#1284985).

Changes for guava:

• Adapt the generated OSGi data to reality
• Upgrade to guava 33.7.2

• Changes of 33.7.2

• collect: Changed MapMaker, CompactHashMap, and CompactHashSet deserialization to avoid eagerly allocating as much memory as a serialization payload requests (bsc#1284985, CVE-2026-102554)

• Changes of 33.7.1

• removes the Multi-Release line from our jar manifest, fixing an issue under Java 9 and 10 that was introduced to guava-jre in version 33.7.0.

• Changes of 33.7.0

• Guava module-info.class is now present at the root of the jar instead of under a multi-release root. This prevents the jar from containing a file at META-INF/versions/9/OSGI-INF/ /MANIFEST.MF, which occasionally causes trouble for some users
• collect: Changed some ImmutableMap implementations to create a new, lightweight object on each call to view methods like keySet(), rather than creating and storing that object during the first call for reuse later. This is likely to slightly improve performance for some users, but it could lead to regressions in unusual cases, such as repeatedly calling asMultimap().inverse() on the same ImmutableMap instance.
• net: Added HttpHeaders constant for on-prefetch-activation.
• net: Added MediaType constants for application/yaml and application/x-pem-file.
• util.concurrent: Fixed ExecutionSequencer queue stall when delegate executor throws RejectedExecutionException.

• Changes of 33.6.0

• Migrated some classes from finalize() to PhantomReference in preparation for the removal of finalization.
• cache: Deprecated CacheBuilder APIs that use TimeUnit in favor of those that use Duration.
• collect: Added toImmutableSortedMap collectors that use the natural comparator.
• collect: Changed ConcurrentHashMultiset, ImmutableMultimap, and TreeMultiset deserialization to avoid mutating final fields. In extremely unlikely scenarios in which an instance of that type contains an object that refers back to that instance, this could lead to a broken instance that throws NullPointerException when used.
• graph: Removed @Beta from all APIs in the package.
• graph: Added support to Graphs.transitiveClosure() for different strategies for adding self-loops.
• graph: Added an asNetwork() view to Graph and ValueGraph.
• hash: Added BloomFilter.serializedSize().
• net: Added HttpHeaders.CDN_CACHE_CONTROL.

• Changes of 33.5.0

• For users of guava-gwt: Google has moved off GWT internally. We plan to continue to release guava-gwt for users of GWT and J2CL, but the artifact is no longer tested for GWT-specific issues, and we have limited resources to fix any unexpected issues that might arise. While we do not anticipate any specific problems, we can't guarantee how long support will continue.
• Listed the JSpecify annotations as an optional dependency in our OSGi metadata.
• cache: Improved the handling of exceptions from compute functions in Cache.asMap(). (We do still recommend using Caffeine rather than com.google.common.cache.)
• collect: Improved Iterators.mergeSorted() to preserve stability for equal elements.
• math: Added saturatedAbs methods to IntMath and LongMath.
• net: Added image/avif to MediaType.
• util.concurrent: Added Striped.custom.

This update for guava fixes the following issue:

• CVE-2026-102554: Allocation of resources without limits or throttling (CWE-770) during Java object deserialization allows an attacker to cause a Denial of Service via OutOfMemoryError (bsc#1284985).

Changes for guava:

• Adapt the generated OSGi data to reality
• Upgrade to guava 33.7.2

• Changes of 33.7.2

• collect: Changed MapMaker, CompactHashMap, and CompactHashSet deserialization to avoid eagerly allocating as much memory as a serialization payload requests (bsc#1284985, CVE-2026-102554)

• Changes of 33.7.1

• removes the Multi-Release line from our jar manifest, fixing an issue under Java 9 and 10 that was introduced to guava-jre in version 33.7.0.

• Changes of 33.7.0

• Guava module-info.class is now present at the root of the jar instead of under a multi-release root. This prevents the jar from containing a file at META-INF/versions/9/OSGI-INF/ /MANIFEST.MF, which occasionally causes trouble for some users
• collect: Changed some ImmutableMap implementations to create a new, lightweight object on each call to view methods like keySet(), rather than creating and storing that object during the first call for reuse later. This is likely to slightly improve performance for some users, but it could lead to regressions in unusual cases, such as repeatedly calling asMultimap().inverse() on the same ImmutableMap instance.
• net: Added HttpHeaders constant for on-prefetch-activation.
• net: Added MediaType constants for application/yaml and application/x-pem-file.
• util.concurrent: Fixed ExecutionSequencer queue stall when delegate executor throws RejectedExecutionException.

• Changes of 33.6.0

• Migrated some classes from finalize() to PhantomReference in preparation for the removal of finalization.
• cache: Deprecated CacheBuilder APIs that use TimeUnit in favor of those that use Duration.
• collect: Added toImmutableSortedMap collectors that use the natural comparator.
• collect: Changed ConcurrentHashMultiset, ImmutableMultimap, and TreeMultiset deserialization to avoid mutating final fields. In extremely unlikely scenarios in which an instance of that type contains an object that refers back to that instance, this could lead to a broken instance that throws NullPointerException when used.
• graph: Removed @Beta from all APIs in the package.
• graph: Added support to Graphs.transitiveClosure() for different strategies for adding self-loops.
• graph: Added an asNetwork() view to Graph and ValueGraph.
• hash: Added BloomFilter.serializedSize().
• net: Added HttpHeaders.CDN_CACHE_CONTROL.

• Changes of 33.5.0

• For users of guava-gwt: Google has moved off GWT internally. We plan to continue to release guava-gwt for users of GWT and J2CL, but the artifact is no longer tested for GWT-specific issues, and we have limited resources to fix any unexpected issues that might arise. While we do not anticipate any specific problems, we can't guarantee how long support will continue.
• Listed the JSpecify annotations as an optional dependency in our OSGi metadata.
• cache: Improved the handling of exceptions from compute functions in Cache.asMap(). (We do still recommend using Caffeine rather than com.google.common.cache.)
• collect: Improved Iterators.mergeSorted() to preserve stability for equal elements.
• math: Added saturatedAbs methods to IntMath and LongMath.
• net: Added image/avif to MediaType.
• util.concurrent: Added Striped.custom.

This update for guava, j2objc-annotations fixes the following issue:

• CVE-2026-102554: Allocation of resources without limits or throttling (CWE-770) during Java object deserialization allows an attacker to cause a Denial of Service via OutOfMemoryError (bsc#1284985).

Changes for guava:

• Upgrade to version 33.7.2

Changes for j2objc-annotations:

• Update to version 3.0.0