Please do not report security vulnerabilities through public GitHub issues, pull requests or mailing lists.

Report them privately to the Apache Security Team at security@apache.org, or to the Apache DataSketches PMC at private@datasketches.apache.org. The Apache Security Team forwards reports to the PMC and coordinates the process described at https://www.apache.org/security/.

Please include the affected version, a description of the issue and, if possible, a way to reproduce it (for example, a serialized sketch that triggers it).

The Apache DataSketches PMC supports only the latest release. Security fixes are made in the next release and are not backported to earlier releases. Users should upgrade to the latest release to receive fixes.

Published vulnerabilities and their advisories are listed at https://datasketches.apache.org/docs/Community/Security.html.

The methods that construct a sketch, union, intersection or filter from serialized data must be safe to call on arbitrary input, including input crafted by an attacker. This includes the heapify(), wrap(), writableWrap(), getInstance() and deserialize() methods that take a MemorySegment, a byte array or a String.

Given a malformed, truncated or corrupt input, these methods must reject it by throwing a RuntimeException. This is usually a SketchesArgumentException, but a standard Java runtime exception, such as IndexOutOfBoundsException or IllegalArgumentException, is also acceptable and often describes the problem more precisely. They must never:

• loop forever, or run for a time far out of proportion to the size of the input;
• allocate memory based on sizes declared in the input that are inconsistent with the rest of the input, or that exceed the documented limits of that sketch type (for example, a current size larger than the declared maximum size, or larger than the configured K allows);
• return a sketch whose internal state is inconsistent, such that a later update, merge, query or serialization of that sketch loops forever or exhausts memory as described above.

Throwing an Error, such as OutOfMemoryError, StackOverflowError or AssertionError, is also not an acceptable way to reject input.

A failure to meet this is treated as a security vulnerability.

The limit on allocation applies to memory that the library allocates while deserializing. A MemorySegment that the caller provides to wrap() or writableWrap() may be larger than the sketch currently needs, for example so that a direct sketch can grow in place without a new allocation. This is supported and is not a violation. The library must not trust any bytes in such a segment beyond the serialized sketch image, and must initialize that space before using it.

Because Java checks array and MemorySegment bounds, a malformed input cannot cause an out-of-bounds read or write of memory. A corrupt input that is accepted, and then causes a runtime exception in a later operation, is a bug and should be reported, but on its own it is not treated as a vulnerability.

Applications that deserialize sketches from untrusted sources should catch RuntimeException, both when deserializing and when using the resulting sketch. Note that a well-formed sketch can legitimately be large. Applications that accept sketches from untrusted sources should limit the size of the input they accept.

Sketches of generic items (for example FrequentItemsSketch, KllItemsSketch and QuantilesItemsSketch) deserialize their items with an ArrayOfItemsSerDe supplied by the caller. The serializers provided by this library are covered by this policy; a serializer written by the application is the application's responsibility.

Other APIs, such as sketch construction parameters, updates, merges and queries, assume a caller that follows the documented preconditions. For example, sketch sizes must be within the documented limits, and a sketch must not be used concurrently from multiple threads without external synchronization. Violating a documented precondition is a bug in the calling application, not a vulnerability in this library.

Sketches produce approximate results with probabilistic error bounds. An adversary who controls the input data can bias the estimates, for example by choosing items that hash to specific values when the hash seed is known. This is inherent to sketching and is not a vulnerability. Applications where this matters should use a secret, non-default seed.