Hi, In my analysis (fuzzing) i find a fancy bug in rsync. Linux bengbeng 2.6.32-26-generic #48-Ubuntu SMP Wed Nov 24 10:14:11 UTC 2010 x86_64 GNU/Linux The Bug: $ rsync --backup-dir=`perl -e 'print "A"x22222;'` Segmentation fault $ rsync --backup-dir=`perl -e 'print "1"x22222;'` Segmentation fault Cheers.
Are you sure that the segmentation violation was in rsync, and not e.g. in the shell used to execute the backticks? Please provide a backtrace of the core dump. I can't reproduce it on my system, I just get the usage message due to incomplete arguments.
Created attachment 6132 [details] core dumped for rsync
I see what is happening. options.c:1496: backup_dir_remainder = sizeof backup_dir_buf - backup_dir_len; if (backup_dir_remainder < 32) { snprintf(err_buf, sizeof err_buf, "the --backup-dir path is WAY too long.\n"); return 0; } But backup_dir_remainder is unsigned, so the subtraction overflows and the error message does not trip.
There's also potential for a one-off overflow here: } else if (backup_dir_buf[backup_dir_len - 1] != '/') { backup_dir_buf[backup_dir_len++] = '/'; backup_dir_buf[backup_dir_len] = '\0'; } backup_dir_len is incremented, but there is no corresponding decrement of backup_dir_remainder.
(In reply to comment #3) > I see what is happening. options.c:1496: > > backup_dir_remainder = sizeof backup_dir_buf - backup_dir_len; > if (backup_dir_remainder < 32) { > snprintf(err_buf, sizeof err_buf, > "the --backup-dir path is WAY too long.\n"); > return 0; > } > > But backup_dir_remainder is unsigned, so the subtraction overflows and the > error message does not trip. I would have expected strlcpy() to limit the return value to the bufsize passed as last argument, but at least the lib/compat.c version doesn't, and contradicts the comments there in doing so ("@return index of the terminating byte"). If it had done that, it would have limited the result of the subtraction to >= 0.
(In reply to comment #2) > Created an attachment (id=6132) [details] > core dumped for rsync A coredump from your system is pretty useless for anyone else. That's why I asked for the backtrace from that coredump. However Matt has spotted the problem already. Amusingly 'file core' says: core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '111111111111111' Note how apparently argv[0] got overwritten as well.
Fix committed to git for both the crashing overflow and the off-by-one issue.