Severity: high Category: security Location:src/shared/protocol.c:176, src/shared/chunk.c:160, src/shared/delta.c:111, src/shared/protocol.c:150
Description:
Multiple protocol deserialization paths allocate memory based on size or count fields received directly from the network peer without any upper bound:
receive_data() allocates malloc((size_t)size) where size is an 8-byte unsigned value from the wire.
receive_str() allocates malloc(size + 1) where size is a size_t from the wire.
chunk_deserialize() allocates malloc(file_data_size) from a received size field.
delta_signature_deserialize() allocates sig->block_count * sizeof(DeltaBlockSig) from a received count.
delta_deserialize() allocates delta->instruction_count * sizeof(DeltaInstruction) from a received count.
A malicious client can send a huge size/count and cause the server to allocate enormous memory, leading to OOM and denial of service. No authentication is required.
Suggested fix:
Add reasonable global and per-message bounds before allocation:
Check size against MAX_WIRE_SIZE and available memory heuristics in receive_data/receive_str. Validate block/instruction counts against MAX_* limits in delta deserialization.
Labels: security, dos
**Severity:** high
**Category:** security
**Location:** `src/shared/protocol.c:176`, `src/shared/chunk.c:160`, `src/shared/delta.c:111`, `src/shared/protocol.c:150`
**Description:**
Multiple protocol deserialization paths allocate memory based on size or count fields received directly from the network peer without any upper bound:
- `receive_data()` allocates `malloc((size_t)size)` where `size` is an 8-byte unsigned value from the wire.
- `receive_str()` allocates `malloc(size + 1)` where `size` is a `size_t` from the wire.
- `chunk_deserialize()` allocates `malloc(file_data_size)` from a received size field.
- `delta_signature_deserialize()` allocates `sig->block_count * sizeof(DeltaBlockSig)` from a received count.
- `delta_deserialize()` allocates `delta->instruction_count * sizeof(DeltaInstruction)` from a received count.
A malicious client can send a huge size/count and cause the server to allocate enormous memory, leading to OOM and denial of service. No authentication is required.
**Suggested fix:**
Add reasonable global and per-message bounds before allocation:
```c
#define MAX_WIRE_SIZE (1ULL << 34) // 16 GB
#define MAX_CHUNK_FILES 100000
#define MAX_DELTA_INSTRUCTIONS 10000000
```
Check `size` against `MAX_WIRE_SIZE` and available memory heuristics in `receive_data`/`receive_str`. Validate block/instruction counts against `MAX_*` limits in delta deserialization.
**Labels:** security, dos
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: high
Category: security
Location:
src/shared/protocol.c:176,src/shared/chunk.c:160,src/shared/delta.c:111,src/shared/protocol.c:150Description:
Multiple protocol deserialization paths allocate memory based on size or count fields received directly from the network peer without any upper bound:
receive_data()allocatesmalloc((size_t)size)wheresizeis an 8-byte unsigned value from the wire.receive_str()allocatesmalloc(size + 1)wheresizeis asize_tfrom the wire.chunk_deserialize()allocatesmalloc(file_data_size)from a received size field.delta_signature_deserialize()allocatessig->block_count * sizeof(DeltaBlockSig)from a received count.delta_deserialize()allocatesdelta->instruction_count * sizeof(DeltaInstruction)from a received count.A malicious client can send a huge size/count and cause the server to allocate enormous memory, leading to OOM and denial of service. No authentication is required.
Suggested fix:
Add reasonable global and per-message bounds before allocation:
Check
sizeagainstMAX_WIRE_SIZEand available memory heuristics inreceive_data/receive_str. Validate block/instruction counts againstMAX_*limits in delta deserialization.Labels: security, dos