cap_im_tg: bound accumulated Telegram HTTP response size

[orbisai0security]

Summary

Adds an upper bound for accumulated Telegram HTTP response data in cap_im_tg_http_event_handler().

Motivation

The current handler grows the response buffer as data arrives. Although the buffer is reallocated before memcpy, an unexpectedly large response can still cause excessive memory growth or OOM on memory-constrained ESP devices.

This change adds a maximum response size check before appending new data, causing oversized responses to fail explicitly instead of continuing to grow the buffer.

Notes

This is defensive hardening / resource-exhaustion protection, not a direct heap buffer overflow fix. The previous description overstated the issue.

Changes

• components/claw_capabilities/cap_im_platform/src/cap_im_tg.c

Verification

• Build passes
• Scanner re-scan confirms fix
• LLM code review passed

---

Automated security fix by OrbisAI Security

[CLAassistant]

All committers have signed the CLA.

[Copilot]

Pull request overview

This PR addresses a critical heap buffer overflow risk in the Telegram IM capability by adding an upper bound to the accumulated HTTP response size during HTTP_EVENT_ON_DATA handling.

Changes:

• Introduced a maximum allowed Telegram HTTP response size (CAP_IM_TG_MAX_RESP_SIZE).
• Added a pre-append guard in cap_im_tg_http_event_handler() to reject responses that would exceed the configured maximum.

---

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

[laride]

Thanks for the report. I agree that bounding the accumulated HTTP response size is useful to avoid excessive memory growth / OOM. However, the current code reallocates the response buffer before memcpy, so this does not appear to be a direct heap buffer overflow in normal execution. Also, TLS certificate verification is configured via esp_crt_bundle_attach. From the current implementation, I’m not sure this should be characterized as a direct CWE-120 heap buffer overflow, but the proposed limit still looks like a useful defensive hardening improvement.

[orbisai0security]

Thanks for taking a look. That makes sense. I agree with your assessment that the current implementation reallocates before memcpy, so this should not be described as a direct CWE-120 heap buffer overflow in normal execution.

I’m happy to reframe this as defensive hardening / resource-exhaustion protection instead: bounding the accumulated Telegram HTTP response size prevents unbounded response growth on a memory-constrained ESP device and makes the failure mode explicit rather than allowing repeated reallocations until OOM.

I’ll update the PR title/description to remove the “critical heap buffer overflow” and TLS/MITM wording, and describe this as a bounded-allocation hardening change. If 64 KiB is not the preferred limit, I’m also happy to adjust it to a project-appropriate constant or make it configurable.