Skip to content

GHSA-p4v4-qxw9-q72m on CTRL-OS 26.05

Aliases: GHSA-p4v4-qxw9-q72m, CVE-2026-70459

Packages: rsync

Status: Plausible

Advisory Information

A malicious peer sends a first incremental file list whose lowest-sorted entry has the basename "." but a non-directory mode. Such an entry never lands in dir_flist, so dir_flist->used stays 0, while the basename test still passes and parent_ndx keeps its flist_new() default of 0. The consumers then dereference dir_flist->files[0] in an array that was never written.

Observed impact is a CRASH, not a disclosure. The dying process is the daemon's GENERATOR, and it dies in generate_files() before any transfer phase -- the file list alone is enough, no transfer-phase index is needed.

The dereferenced slot is NOT guaranteed to be NULL: dir_flist->files[] comes from realloc(), not calloc(). In an ordinary run it does read as NULL (the fault address is 0x14, matching file->mode), but a peer that grooms the heap first -- requesting --delete and sending a large filter list that it then frees before the file list is parsed -- can place its own bytes in that slot. That was demonstrated on an instrumented build, which logged the parent pointer as 0x4141414141414141; against an unmodified released 3.4.1 the same grooming changed the fault from SEGV_MAPERR to SI_KERNEL, consistent with dereferencing that non-canonical pointer.

So this is an uninitialised / wild pointer dereference, normally observed as a NULL or invalid-pointer SIGSEGV, and the pointer's contents are within the peer's influence. No disclosure, code execution, or attacker-chosen valid address has been demonstrated; the demonstrated outcome remains a remote DoS of the connection.

Reproduced against unmodified released daemons: rsync 3.2.7, 3.4.0 and 3.4.1 each segfault the connection child on an anonymous writable module.

Reachable on any anonymous writable module (PR:N). It is NOT pre-authentication -- it is reached after module access and setup. It is distinct from CVE-2026-43620 (a negative parent_ndx, fixed in 3.4.3): here the index is in-range-looking but the array it indexes is empty.

Fixed at the root in recv_file_list() by requiring dir_flist to hold an entry before index 0 is trusted, with a bound at each of the three consumers (receiver.c, generator.c x2) as defence in depth. On 3.5.0 a later change also refuses a non-directory transfer-root entry outright at parse time, so the attack shape is stopped three separate ways; a backport of the recv_file_list() fix alone is sufficient, and was verified sufficient in isolation.

Affected: 3.0.0 through 3.4.4 (incremental recursion entered in 3.0.0); reproduced on released 3.2.7, 3.4.0 and 3.4.1

Fixed in: 3.5.0

Reporter: Greg Kroah-Hartman (daemon-protocol fuzzing); companion to CVE-2026-43620

Test: proto-parent-ndx-empty-dirflist

Updates

2026-08-14 16:57 CEST

Metadata changes:

  • Status for package rsync: “Plausible”

2026-08-14 16:55 CEST

Metadata changes:

  • Status for package rsync: “New”