GHSA-RRJR-V56M-WW88: Stack Exhaustion Denial of Service in ParquetSharp DecimalConverter

ParquetSharp is a .NET library that provides a high-performance wrapper around the Apache Parquet C++ library. Applications use ParquetSharp to read and write Parquet files, a columnar storage format frequently employed in data engineering and analytics workloads. The vulnerability exists within the parsing mechanism for decimal data types stored as Fixed-Length Byte Arrays (FLBA).

When processing Parquet files, the library extracts metadata defining the physical structure of the columns, including the length of byte arrays used for decimal values. The DecimalConverter component utilizes this metadata to allocate memory during read operations.

The library fails to enforce an upper bound on the Length property derived from the untrusted file metadata. This architectural oversight classifies the defect as CWE-121, representing a stack-based buffer overflow specifically manifesting as stack exhaustion.

The technical root cause originates in the DecimalConverter.ReadDecimal and DecimalConverter.WriteDecimal methods. In .NET, the stackalloc keyword allows developers to allocate memory directly on the thread's execution stack rather than the managed heap. This technique bypasses garbage collection overhead and provides significant performance benefits for small, temporary buffers.

The vulnerability occurs because the stackalloc instruction receives its size parameter directly from the byteArray.Length property. This property represents the primitiveLength defined in the Parquet file's metadata schema.

Because the Parquet format allows files to self-describe their schema, an attacker maintains complete control over the primitiveLength value. When the application attempts to allocate an excessively large buffer, such as 10 megabytes, the allocation exceeds the thread's maximum stack size limit, which typically defaults to 1 megabyte in standard .NET environments.

The vulnerable implementation relies entirely on stack allocation regardless of the requested buffer size. The DecimalConverter method receives a ByteArray object and immediately initiates a stackalloc operation.

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static unsafe decimal ReadDecimal(ByteArray byteArray, decimal multiplier)
{
    if (byteArray.Length == 0) return new decimal(0);
 
    // Unbounded stack allocation based on untrusted length
    var tmp = stackalloc byte[byteArray.Length]; 
    for (var byteIdx = 0; byteIdx < byteArray.Length; ++byteIdx)
    {
        tmp[byteArray.Length - byteIdx - 1] = *((byte*) byteArray.Pointer + byteIdx);
    }
    // ...
}

The patch resolves this by introducing a maximum threshold for stack allocations, defined as MaxStackAllocSize with a value of 1024 bytes. If the requested typeLength is less than or equal to this constant, the code maintains the high-performance stackalloc path.

If the requested length exceeds 1024 bytes, the patched code falls back to renting a buffer from the managed heap using ArrayPool<byte>.Shared.Rent. A finally block guarantees the buffer returns to the pool after the read operation completes, preventing memory leaks while safely handling arbitrarily large metadata values.

Exploitation requires the attacker to deliver a maliciously crafted Parquet file to a vulnerable application endpoint. The attacker structures the file with a decimal-type column utilizing the FIXED_LEN_BYTE_ARRAY physical type.

The attacker then modifies the file metadata to specify a disproportionately large primitiveLength for the decimal column. The specific value only needs to exceed the target environment's thread stack limit to guarantee a crash.

When the target application instantiates a ParquetFileReader and attempts to read the compromised column, the execution flow reaches the DecimalConverter.ReadDecimal method. The following proof-of-concept snippet demonstrates the precise API call sequence that triggers the condition.

using var decimalType = LogicalType.Decimal(precision: 9, scale: 4);
using var colNode = new PrimitiveNode("value", Repetition.Required, decimalType, PhysicalType.FixedLenByteArray, primitiveLength: 10_000_000);
using var schema = new GroupNode("schema", Repetition.Required, new Node[] { colNode });
 
// The groupReader parses the modified schema and passes the large length
using var columnReader = groupReader.Column(0).LogicalReader<decimal>();
// ReadAll triggers the unbounded stackalloc
var values = columnReader.ReadAll((int) groupReader.MetaData.NumRows);

The vulnerability consistently results in a Denial of Service condition against the host application. In the .NET runtime, a StackOverflowException fundamentally differs from standard exceptions.

The runtime immediately terminates the executing process when a stack overflow occurs. Developers cannot intercept or handle a StackOverflowException using standard try-catch blocks, making the crash unavoidable once the vulnerable execution path triggers.

This termination affects all concurrent operations running within the application process. If the vulnerable ParquetSharp implementation operates within a web service or data ingestion pipeline, a single malicious file payload will cause complete service disruption, requiring a process restart to restore availability.

Organizations must update the ParquetSharp NuGet package to version 23.0.0.1 to eliminate the vulnerability. This version incorporates the ArrayPool fallback mechanism, which neutralizes the stack exhaustion vector while preserving parsing performance for standard files.

If immediate patching is unfeasible, developers should implement pre-processing validation on incoming Parquet files. This validation layer must inspect the logical schema and reject files containing decimal columns with a primitiveLength exceeding expected operational limits.

Security teams should also review dependency trees to identify indirect usages of ParquetSharp. Static analysis tools can detect invocations of ParquetSharp.DecimalConverter.ReadDecimal or ParquetSharp.ColumnReader<decimal>.ReadAll() to prioritize remediation efforts across large codebases.