Fix ssl_DecodePacketInternal chain processing

[embhorn]

Description

Problem: The chain accumulation loop summed size_t (64-bit) iov_len values into an int (32-bit) length, causing silent truncation. An undersized buffer was allocated, then full data was copied causing a heap overflow.

Fixes zd21388

Testing

Added test_sniffer_chain_input_overflow

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[Copilot]

Pull request overview

This PR fixes a heap overflow in ssl_DecodePacketInternal when processing chained input by preventing size_t → int truncation during total-length accumulation, and adds a regression test to ensure oversized chains are rejected.

Changes:

• Accumulate iovec chain length using size_t with overflow/INT_MAX bounds checks before allocating/copying.
• Add a sniffer chain-input regression test covering overflow/oversize scenarios.
• Register the new test case behind the sniffer chain-input feature macros.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/sniffer.c	Fixes chain-length accumulation to avoid truncation and detect overflow/oversize before allocation/copy.
tests/api.c	Adds and registers a regression test that exercises oversize chain inputs.

Comments suppressed due to low confidence (4)

tests/api.c:1

• The comment says the total is exactly at the INT_MAX boundary, but the configured lengths sum to INT_MAX + 1 (since chain[1].iov_len = 1 and chainSz is 2). Either update the comment to match the actual boundary-overrun being tested, or adjust the inputs to truly hit exactly INT_MAX if that’s the intended case.
  tests/api.c:1
• The test asserts the return code, but it doesn’t verify that data remains untouched on error (which is part of the safety guarantee described in the comments), and it also reuses data across both calls without resetting/cleaning it. Consider asserting data == NULL after each failing call (and/or resetting data before the second call) to both strengthen the regression coverage and avoid inadvertent leaks if behavior changes.
  tests/api.c:1
• The test asserts the return code, but it doesn’t verify that data remains untouched on error (which is part of the safety guarantee described in the comments), and it also reuses data across both calls without resetting/cleaning it. Consider asserting data == NULL after each failing call (and/or resetting data before the second call) to both strengthen the regression coverage and avoid inadvertent leaks if behavior changes.
  tests/api.c:1
• The test asserts the return code, but it doesn’t verify that data remains untouched on error (which is part of the safety guarantee described in the comments), and it also reuses data across both calls without resetting/cleaning it. Consider asserting data == NULL after each failing call (and/or resetting data before the second call) to both strengthen the regression coverage and avoid inadvertent leaks if behavior changes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.