chunk_size truncated to int during wire transfer — values > 2GB silently corrupted #49

New Issue

2026-07-20T17:12:55+02:00

TapTap commented

2026-07-20 17:12:55 +02:00

Description

In src/shared/config.c line 113, config_send() casts config->chunk_size (an unsigned long long) to int for transmission:

if (!send_int(file_descriptor, (int)config->chunk_size))

The same truncation happens in the reverse direction on line 188:

config->chunk_size = (unsigned long long)tmp;  // tmp is int

And similarly for delta_block_size on lines 123 and 203.

Impact

If the user specifies --chunk-size 3000000000 (3GB, well within unsigned long long range), the value is silently truncated to a negative or garbage int before being sent over the wire. The receiving side gets an incorrect chunk size.

While the default chunk size (10MB) and most practical values fit in int, this is a latent correctness bug that violates the principle that the full unsigned long long range should be supported.

Location

src/shared/config.c:113, 123, 188, 203

Suggested Fix

Instead of send_int/receive_int, use send_n_data/receive_n_data with sizeof(unsigned long long) to transmit these 64-bit values correctly:

// Sender:
if (!send_n_data(file_descriptor, &config->chunk_size, sizeof(config->chunk_size)))
    return false;

// Receiver:
if (!receive_n_data(file_descriptor, &config->chunk_size, sizeof(config->chunk_size)))
    goto error;

Severity

High

Category

Bug

This issue was automatically generated by the issue-creator agent.

## Description In `src/shared/config.c` line 113, `config_send()` casts `config->chunk_size` (an `unsigned long long`) to `int` for transmission: ```c if (!send_int(file_descriptor, (int)config->chunk_size)) ``` The same truncation happens in the reverse direction on line 188: ```c config->chunk_size = (unsigned long long)tmp; // tmp is int ``` And similarly for `delta_block_size` on lines 123 and 203. ## Impact If the user specifies `--chunk-size 3000000000` (3GB, well within `unsigned long long` range), the value is silently truncated to a negative or garbage `int` before being sent over the wire. The receiving side gets an incorrect chunk size. While the default chunk size (10MB) and most practical values fit in `int`, this is a latent correctness bug that violates the principle that the full `unsigned long long` range should be supported. ## Location `src/shared/config.c:113, 123, 188, 203` ## Suggested Fix Instead of `send_int`/`receive_int`, use `send_n_data`/`receive_n_data` with `sizeof(unsigned long long)` to transmit these 64-bit values correctly: ```c // Sender: if (!send_n_data(file_descriptor, &config->chunk_size, sizeof(config->chunk_size))) return false; // Receiver: if (!receive_n_data(file_descriptor, &config->chunk_size, sizeof(config->chunk_size))) goto error; ``` ## Severity High ## Category Bug --- _This issue was automatically generated by the issue-creator agent._

TapTap referenced this issue from a commit

2026-07-20 18:44:11 +02:00

fix: memory/null safety bugs — issues #74, #72, #69, #64, #60, #50, #49, #65

TapTap closed this issue

2026-07-20 18:44:16 +02:00

TapTap referenced this issue

2026-07-20 18:44:16 +02:00

Fix memory/null safety bugs (#74, #72, #69, #64, #60, #50, #49, #65) #80

TapTap referenced this issue from a commit

2026-07-20 18:56:39 +02:00

fix: memory/null safety bugs — issues #74, #72, #69, #64, #60, #50, #49, #65

TapTap referenced this issue from a commit