Backport upstream commit c44c90e9460c to fix CVE-2026-43618, an integer overflow in compressed-token decoding. The patch adds MAX_TOKEN_INDEX bounds checking and new helper functions (recv_compressed_token_num, recv_compressed_token_run, invalid_compressed_token) to harden the recv_deflated_token decoder against overflow of the rx_token counter. It also caps simple_recv_token literal-block length at CHUNK_SIZE and adds a safety check for NULL data pointers in receiver.c. The patch was adapted for rsync 3.1.3 which only has the zlib decoder (recv_deflated_token), skipping hunks for zstd/lz4 decoders not present in this version.
Upstream patches:
c44c90e946.patch
Triage Decision Justification: CVE-2026-43618 describes a remote memory disclosure vulnerability via integer overflow in rsync's compressed-token decoding. The receiver's compressed-token decoders accumulated rx_token (a 32-bit signed counter) without overflow checking. A malicious sender could craft a compressed-token stream that walked rx_token past INT32_MAX, leaking process memory contents (environment variables, passwords, heap pointers) and weakening ASLR. Upstream commit c44c90e9460c666c965446a8c0957f0b9fa4c66a on master, authored by Andrew Tridgell on 2026-04-29, directly fixes this vulnerability by: (1) capping rx_token at MAX_TOKEN_INDEX = 0x7ffffffe, (2) introducing shared recv_compressed_token_num() and recv_compressed_token_run() functions with comprehensive validation, (3) rejecting negative or out-of-range token values explicitly, and (4) capping simple_recv_token literal-block length at CHUNK_SIZE. While the patch does not explicitly mention CVE-2026-43618, its commit message exactly describes the vulnerability: 'integer overflow in compressed-token decoding' causing 'remote memory disclosure', matching the CVE summary precisely. Note: RHEL 8 ships rsync 3.1.3 which only has recv_deflated_token() (no zstd/lz4), so the patch will require manual adaptation for the older codebase. The upstream patch also supersedes an earlier precursor commit (359e539a, 'reject negative token values') which is already incorporated into and replaced by the comprehensive c44c90e9 fix.
Resolves: RHEL-174951
Backporting steps:
Successfully backported upstream commit c44c90e9460c666c965446a8c0957f0b9fa4c66a (CVE-2026-43618) to rsync 3.1.3 on c8s.
The upstream patch hardens compressed-token decoding against integer overflow in token.c and adds safety checks in receiver.c. The patch targets a newer rsync version that includes zstd and lz4 compression support (recv_zstd_token and recv_compressed_token functions), which don't exist in v3.1.3.
Conflict resolution:
Hunks for receiver.c applied cleanly (offset -13 lines).
Hunks adding the new helper functions (invalid_compressed_token, recv_compressed_token_num, recv_compressed_token_run, MAX_TOKEN_INDEX) and the simple_recv_token CHUNK_SIZE check applied cleanly.
Hunk #3 (replacing inline token parsing in recv_deflated_token with recv_compressed_token_num call) failed because the v3.1.3 code differs slightly from the newer version (no rx_token < 0 check in original). Manually replaced the old inline token parsing code with the new recv_compressed_token_num(f, flag) call.
Hunk #4 (r_running case in recv_deflated_token using recv_compressed_token_run) applied cleanly.
Hunks for recv_zstd_token and recv_compressed_token (lz4) were correctly skipped as those functions don't exist in v3.1.3 - only recv_deflated_token (zlib) is present.
The core security fix (overflow protection via MAX_TOKEN_INDEX bounds checking and the new helper functions) is fully applied to the only compression decoder that exists in this version.
df410d7cbf