Fix: Integer Truncation in PatternLayout causing heap corruption with large logs

[OxBat]

Summary

I identified a critical integer truncation vulnerability in PatternLayout::format. The code explicitly casts the 64-bit buffer length (size_t) to a signed 32-bit integer (int).

On 64-bit systems, if a log message exceeds 2GB (e.g., large JSON dumps or accumulated stack traces), the length wraps around to a negative number. This negative index is then passed to downstream formatters, leading to out-of-bounds memory access (heap corruption) or segmentation faults.

Technical Analysis

In src/main/cpp/patternlayout.cpp (around line 130):

// Vulnerable Code:
int startField = (int)output.length();

When output.length() > INT_MAX, startField becomes negative. This startField is subsequently used for pointer arithmetic or string indexing in FormattingInfo, causing the crash.

Remediation
This patch removes the unsafe cast and updates the variable type to size_t to correctly handle the return type of std::string::length().

Steps to Reproduce (Logic)

1. Configure a PatternLayout with %m.
2. Log a message string larger than 2GB on a 64-bit build.
3. The cast to int truncates the size, resulting in a negative offset.

[rm5248]

it looks like you have some odd indentation here.

the comment is also not helpful, can we remove it?

[OxBat]

I've removed the comment and fixed the indentation

[swebb2066]

The proposed change does not correct the problem as the truncation still occurs when passing startField to FormattingInfo::format as its signature is:
void FormattingInfo::format(const int fieldStart, LogString& buffer) const

I suggest the correct solution is not calling FormattingInfo::format if the length exceeds INT_MAX

[swebb2066]

Resolved by #593