Unbounded new int[length] from declared array length in Input.readInts → OutOfMemoryError on malformed input

[joszamama]

Describe the bug

When reading a primitive array, Kryo allocates the array from the declared length before validating it against the bytes actually remaining in the input. A few-byte input that declares a huge length causes an immediate OutOfMemoryError (new int[length] with no bound). Input.readInts and its siblings (readLongs/readFloats/readDoubles/...) and the array/collection serializers share this pattern.

Reporting this as a robustness/hardening issue. I am aware Kryo is not intended for deserializing untrusted data; filing in case bounding the initial allocation is considered worthwhile.

To Reproduce

Minimal runnable example (5-byte input):

import com.esotericsoftware.kryo.Kryo;
import com.esotericsoftware.kryo.io.*;

public class KryoPoc {
  public static void main(String[] a) {
    Kryo kryo = new Kryo();
    kryo.register(int[].class);          // typical application registration
    Output o = new Output(16);
    o.writeVarInt(2000000001, true);     // length+1 -> declared int[] length 2,000,000,000
    o.flush();
    byte[] evil = o.toBytes();           // 5 bytes; no element payload follows
    kryo.readObject(new Input(evil), int[].class);   // OutOfMemoryError here
  }
}

Result:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at com.esotericsoftware.kryo.io.Input.readInts(Input.java:968)

The input declares a 2,000,000,000-element array but carries no element data; Kryo allocates new int[2000000000] before checking that the input could possibly contain that many elements.

Environment:

• OS: macOS 26.5.1 (25F80)
• JDK Version: 21
• Kryo Version: 5.6.2 (latest)

Suggested fix

Bound the initial allocation to the bytes remaining in the input (a primitive element is at least 1 byte, so the declared length cannot exceed the remaining byte count), or read and grow in chunks rather than pre-allocating the full declared length. Found via boundary-value testing as part of academic research.

[theigl]

Thanks for the report. This is a known limitation of Kryo, which assumes that data comes from a trusted source.

Implementing some kind of reasonable guardrails for deserialization would definitely make sense. Not only for arrays and collections, but also for Strings.

The specific case you are reporting (primitive arrays) might actually be fixable with the heuristic you are suggesting.

PRs would be welcome.

[joszamama]

Thank you for your quick answer! I will provide a fix and validate it using my current testing workflow to ensure there are no other potential similarities.

[joszamama]

Hi, I just provided a fix (#1284) for this specific issue, and for related OutOfMemoryError problems I found per your suggestion: "Not only for arrays and collections, but also for Strings". I've explained all my design choices directly in the PR; I hope it helps.

The most important decision was maxArraySize: the configurable limit (default off). For performance reasons, I implemented the approach of other parser libraries like Avro (collectionItems.maxLength, default unlimited).

Let me know if there are any problems or if you have any questions.