Critical integer overflow leading to heap buffer overflow in TS payload handling #891

New Issue

claunia · 2026-01-29T16:56:22Z

claunia commented

2026-01-29 16:56:22 +00:00

Originally created by @THE-Amrit-mahto-05 on GitHub (Jan 4, 2026).

Summary

A critical integer overflow exists in the TS payload handling logic where a calculated buffer size exceeds INT_MAX and is stored in a signed integer. This results in a negative buffer size, leading to undersized memory allocation and potential heap buffer overflow.

Impact

Fully attacker-controlled input
Integer overflow
Undersized realloc/malloc
Heap buffer over-read / write
Potential Remote Code Execution (RCE)

Root Cause

The buffer resize calculation does not properly guard against integer overflow when computing the new capture buffer length. When the calculated value exceeds the maximum representable signed integer, it wraps into a negative value.

Proof of Concept

I reproduced the overflow using a minimal runtime test.

Observed output:

newcapbuflen = 2147483657
capbufsize after overflow = -2147483639

Minimal Reproducer

The following minimal C program demonstrates the signed integer overflow in buffer size calculation:
This reproducer models the exact signed integer addition used in the TS payload resize logic and demonstrates how the same calculation overflows at runtime.

#include <stdio.h>
#include <limits.h>

int main(void) {
    int capbufsize = INT_MAX - 10;
    int payload_len = 20;

    int newcapbuflen = capbufsize + payload_len;

    printf("newcapbuflen = %d\n", newcapbuflen);
    printf("capbufsize after overflow = %d\n", newcapbuflen);

    return 0;
}

How to reproduce

gcc -g minimal_overflow_test.c -o minimal_overflow_test
./minimal_overflow_test

Output

newcapbuflen = 2147483657
capbufsize after overflow = -2147483639

Affected Code Path

In src/lib_ccx/ts_functions.c, the buffer resize logic computes:

newcapbuflen = cinfo->capbuflen + payload->length;

When payload->length is attacker‑controlled and sufficiently large, this addition overflows a signed integer, resulting in a negative newcapbuflen. This value is later used for memory reallocation, leading to an undersized buffer followed by out‑of‑bounds writes.

If this assessment looks correct, I’m happy to open a PR with a fix.

Originally created by @THE-Amrit-mahto-05 on GitHub (Jan 4, 2026). ### Summary A critical integer overflow exists in the TS payload handling logic where a calculated buffer size exceeds INT_MAX and is stored in a signed integer. This results in a negative buffer size, leading to undersized memory allocation and potential heap buffer overflow. ### Impact - Fully attacker-controlled input - Integer overflow - Undersized realloc/malloc - Heap buffer over-read / write - Potential Remote Code Execution (RCE) ### Root Cause The buffer resize calculation does not properly guard against integer overflow when computing the new capture buffer length. When the calculated value exceeds the maximum representable signed integer, it wraps into a negative value. ### Proof of Concept I reproduced the overflow using a minimal runtime test. ### Observed output: newcapbuflen = 2147483657 capbufsize after overflow = -2147483639 ### Minimal Reproducer The following minimal C program demonstrates the signed integer overflow in buffer size calculation: This reproducer models the exact signed integer addition used in the TS payload resize logic and demonstrates how the same calculation overflows at runtime. ```c #include <stdio.h> #include <limits.h> int main(void) { int capbufsize = INT_MAX - 10; int payload_len = 20; int newcapbuflen = capbufsize + payload_len; printf("newcapbuflen = %d\n", newcapbuflen); printf("capbufsize after overflow = %d\n", newcapbuflen); return 0; } ``` ### How to reproduce gcc -g minimal_overflow_test.c -o minimal_overflow_test ./minimal_overflow_test ### Output newcapbuflen = 2147483657 capbufsize after overflow = -2147483639 ### Affected Code Path In src/lib_ccx/ts_functions.c, the buffer resize logic computes: ```c newcapbuflen = cinfo->capbuflen + payload->length; ``` When payload->length is attacker‑controlled and sufficiently large, this addition overflows a signed integer, resulting in a negative newcapbuflen. This value is later used for memory reallocation, leading to an undersized buffer followed by out‑of‑bounds writes. If this assessment looks correct, I’m happy to open a PR with a fix.

claunia closed this issue

2026-01-29 16:56:22 +00:00

claunia commented

2026-01-29 16:56:23 +00:00

@cfsmp3 commented on GitHub (Jan 4, 2026):

I'd like a see a repro in CCExtractor - i.e. an actual input file that will trigger it, not a C program that overflows, of course that's trivial.

As I said, we're migrating to Rust, so this is just not something we should be spending time on - unless it's a problem we can see in CCExtractor right now and therefore needs fixing.

@cfsmp3 commented on GitHub (Jan 4, 2026): I'd like a see a repro in CCExtractor - i.e. an actual input file that will trigger it, not a C program that overflows, of course that's trivial. As I said, we're migrating to Rust, so this is just not something we should be spending time on - unless it's a problem we can see in CCExtractor right now and therefore needs fixing.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#891