fluentforwardreceiver allocates arbitrary memory from attacker-controlled msgpack length prefixes

[aniket866]

Vulnerability Detail

The fluent_forward receiver (receiver/fluentforwardreceiver) decodes incoming msgpack frames from peer connections.
Previously, several decode paths in conversion.go read 32-bit length prefixes from the incoming stream and used them directly to allocate Go data structures (via EnsureCapacity or make(map[string]any, hint)) and drive iteration loops, without any size checks.

This allowed an unauthenticated attacker to send a few bytes and force the collector to attempt multi-gigabyte allocations, triggering an out-of-memory (OOM) crash or causing CPU exhaustion.

Fix Implementation

To prevent this vulnerability:

1. We introduced a limit constant:

   const maxFluentArrayLen = 1 << 20 // 1,048,576 elements

2. We placed guard validation checks immediately after reading map and array headers in:
   • parseRecordToLogRecord (map headers)
   • parseOptions (map headers)
   • forwardEventLogRecords.DecodeMsg (array headers)
3. If any header indicates a length larger than maxFluentArrayLen, we abort parsing immediately and return an error without performing allocations.

How it Works Now

• Safe Allocation: Any frame specifying a length larger than 1 << 20 is immediately rejected. The memory allocation (EnsureCapacity or make) is never executed, preventing memory exhaustion.

• Robust Iteration: Loops are bound to a maximum size of 1 << 20, protecting against infinite/unbounded execution.

• Validation: Added a dedicated unit test suite TestDecodeMsgExcessiveLengths to verify rejection behavior.

• I, a human, wrote this pull request description myself.

Closes #49229

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Read our Contributing Guidelines.
• Sign the CLA if you haven't already.
• First-time contributors should have at most one PR not marked as draft until their first PR is merged.
• If your change isn't one of our priority components, reviews may take more time.
• Give reviewers at least a few days before pinging them for feedback.
• If you need help or struggle to move your PR forward:
  • Ask questions regarding general setup, development process, or contributor etiquette in #opentelemetry-new-contributors.
  • Raise technical or Collector-specific questions in #otel-collector-dev or a Collector SIG meeting.

[aniket866]

hi @singhvibhanshu this is also ready to be reviewed , Please do whenever you get time

[opentelemetry-pr-dashboard]

Pull request dashboard status

Status last refreshed: 2026-07-27 15:22:38 UTC.

• Waiting on: Author
• Next step: Investigate required status check failures.

This automated status or its linked feedback items may be incorrect. If something looks wrong, please report it with the result you expected. If you believe this pull request is incorrectly routed as waiting on the author, comment /dashboard route:reviewers to route it from waiting on the author to waiting on reviewers. If the last refreshed time above predates your latest reply or push, the dashboard hasn't processed it yet.