Variant parsing is vulnerable to memory-DoS and malformed-input crashes

[rdblue]

This issue was reported to the private Apache Iceberg security mailing list. The submitter is being kept anonymous because the report was sent to a private list. After review, the issue is not considered a serious vulnerability that needs to be kept private, so it is being filed publicly here for tracking and resolution.

Note: this submission was generated by AI. Please review its claims and source references carefully before acting on them.

Summary

Malformed variant buffers can force large allocations and raw JVM
exceptions before structural validation, turning small
attacker-controlled payloads into a read-time denial of service path.

Affected Maven coordinates

• primary shipped client artifact: org.apache.iceberg:iceberg-api

Attacker prerequisites

• Any consumer that parses variant values from untrusted or
  semi-trusted Iceberg content is exposed.
• The easiest attack is a tiny payload that advertises a very large
  element count or dictionary size.

Impact

• A malicious variant payload can force large allocations before the
  payload is structurally validated.
• The same code path can also fail with raw JVM exceptions such as
  NegativeArraySizeException, ArrayIndexOutOfBoundsException, and
  IndexOutOfBoundsException instead of a typed validation failure.
• In a service that reads attacker-controlled tables or records, this
  is a straightforward availability issue.

Proof status

Source review only. The issue is visible directly from source.

Key source references

• org.apache.iceberg.variants.Variant
• org.apache.iceberg.variants.VariantValue
• org.apache.iceberg.variants.SerializedMetadata
• org.apache.iceberg.variants.SerializedArray
• org.apache.iceberg.variants.SerializedObject

[nssalian]

I'd like to work on this.
@rdblue do you mind assigning this to me?

[rdblue]

@nssalian, thanks for looking into this!

In the Iceberg project, we don't assign issues to people. That tends to prevent them from moving forward more than it deduplicates effort. It's rare that two people decide to work on the same issue and assigning issues to just one person signals that no one else should work on it. That's not great when contributors, understandably, end up not having as much time as they originally thought. So we leave issues unassigned and rely on people to communicate about how to get them done. Just stepping up to work on it should be fine. Thank you!

[nssalian]

Appreciate it. I'll put up a fix for this.
@steveloughran has an open item in Parquet for malformed metadata too: apache/parquet-java#3562 and in iceberg as well #16335

[rdblue]

I'm removing the security label from this. It is more of a potential bug than a security issue.

[RussellSpitzer]

Agreed, not a security issue because it's an OOM and also because a legitimate payload could also cause an OOM but worth hardening.

[nssalian]

Makes sense to keep this as a bug. I'll work with @steveloughran to see how to add the fixes.

[steveloughran]

the only marginal security issue is that OOM on multiplication overflow could affect other workers; the others are just "bad data fails differently from expected", and the checks just bring faliure forward. parquet C++ probably needs the most auditing here, as parquet rs hasgreat validation in.

@rdblue see also (and please help review!)

• parquet-java hardening with tests GH-3561 Harden variants against malformed metadata. parquet-java#3562
• reference malformed test data for parquet-testing: GH-112 Harden variant decoding: example data parquet-testing#113

One purely subjective issue (as raised on parquet dev list) is what is a good depth limit? I went with 500 to match that of the json parser.