After the fix for CVE-2018-1000001, getcwd returns ENOENT if the current directory is unreachable and does not have a name.

This happens because this:

	/* Initialize change_dir() here because on some old systems getcwd
	 * (implemented by forking "pwd" and reading its output) doesn't
	 * work when there are other child processes.  Also, on all systems
	 * that implement getcwd that way "pwd" can't be found after chroot. */
	change_dir(NULL, CD_NORMAL);

And this:

/* Like chdir(), but it keeps track of the current directory (in the
 * global "curr_dir"), and ensures that the path size doesn't overflow.
 * Also cleans the path using the clean_fname() function. */
int change_dir(const char *dir, int set_path_only)
{
	static int initialised, skipped_chdir;
	unsigned int len;

	if (!initialised) {
		initialised = 1;
		if (getcwd(curr_dir, sizeof curr_dir - 1) == NULL) {
			rsyserr(FERROR, errno, "getcwd()");
			exit_cleanup(RERR_FILESELECT);
		}
		curr_dir_len = strlen(curr_dir);
	}

This error is reached even if all input paths to rsync are absolute and the current directory path is never needed.

To trigger this, it is sufficient to execve rsync from a process whose current directory has a pending lazy umount (MNT_DETACH/umount -l).  The execve makes the current directory unreachable in the new process image (at least on kernel 4.14.14).

Reportedly, this break glusterfs geo-replication.

References:

https://lists.gluster.org/pipermail/gluster-users/2018-January/033293.html
https://sourceware.org/ml/libc-alpha/2018-02/msg00152.html
https://bugs.launchpad.net/bugs/1746995