-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rsync crashes with "*** buffer overflow detected ***: terminated" #511
Comments
Adding a very simple reproducer on localhost:
Removing -F helps:
|
Fortified (-D_FORTIFY_SOURCE=2 for gcc) builds make strlcpy() crash when its third parameter (size) is larger than the buffer: $ rsync -FFXHav '--filter=merge global-rsync-filter' Align-37-43/ xxx sending incremental file list *** buffer overflow detected ***: terminated It's in the exclude code in setup_merge_file(): strlcpy(y, save, MAXPATHLEN); Note the 'y' pointer was incremented, so it no longer points to memory with MAXPATHLEN "owned" bytes. Fix it by remembering the number of copied bytes into the 'save' buffer and use that instead of MAXPATHLEN which is clearly incorrect. Fixes RsyncProject#511.
I tried to reproduce this bug on Debian in order to confirm whether we were affected or not (and whether it made sense to backport the fix), and that got me into a rabbit hole. Allow me to explain. Neither the bug description nor the PR description are very clear regarding the reproduction steps. My initial attempt was to run the reproducer provided by @mruprich , but that failed to trigger the issue. Debian uses After reading the implementation of glibc's /* Fortify support. */
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)
#define __bos0(ptr) __builtin_object_size (ptr, 0)
/* Use __builtin_dynamic_object_size at _FORTIFY_SOURCE=3 when available. */
#if __USE_FORTIFY_LEVEL == 3 && (__glibc_clang_prereq (9, 0) \
|| __GNUC_PREREQ (12, 0))
# define __glibc_objsize0(__o) __builtin_dynamic_object_size (__o, 0)
# define __glibc_objsize(__o) __builtin_dynamic_object_size (__o, 1)
#else
# define __glibc_objsize0(__o) __bos0 (__o)
# define __glibc_objsize(__o) __bos (__o)
#endif A little bit of debugging told me that In summary, the conclusion is that the bug only happens when rsync is compiled against glibc >= 2.38 and with I went through all this trouble because the rsync code that trips this crash actually made sense to me ( |
To add on to @sergiodj's comment, there's no real buffer overflow happening, this is a false positive from the fortified function. This is implied from his explanation but I wanted to make it clear. |
Yes, it's a false positive. I don't know why I didn't add a downstream link: https://bugzilla.suse.com/show_bug.cgi?id=1214249. See: |
See RsyncProject/rsync#511 for details. Not using fetchpatch, because I didn't found a raw link for opensuse's repository
See RsyncProject/rsync#511 for details. Not using fetchpatch, because I didn't found a raw link for opensuse's repository
See RsyncProject/rsync#511 for details. Not using fetchpatch, because I didn't found a raw link for opensuse's repository
See RsyncProject/rsync#511 for details. Not using fetchpatch, because I didn't found a raw link for opensuse's repository
See RsyncProject/rsync#511 for details. Not using fetchpatch, because I didn't found a raw link for opensuse's repository
See RsyncProject/rsync#511 for details. Not using fetchpatch, because I didn't found a raw link for opensuse's repository
See RsyncProject/rsync#511 for details. Not using fetchpatch, because I didn't found a raw link for opensuse's repository
Not really, the fortification check is explicit about the destination and size relationship in the The fortification abort error messages could benefit some nuance though, because unlike what they claim, they don't trigger at the point of (or just before) a buffer overflow. The fortifications trigger when they detect a potential for buffer overflow, which is subtly different. |
Using rsync 3.3.0pre1 compiled on Ubuntu:jammy and gcc-12 I have had no issue. But compiling the same rsync with gcc-13 on Ubuntu:noble. And then using rsync in a kernel build gives me the same error. (This is with the patch #513) included. So there must be another code with a similar issue. With rsync-3.2.7 I did not get this error (on either jammy or noble.)
|
Fortified (-D_FORTIFY_SOURCE=2 for gcc) builds make strlcpy() crash when its third parameter (size) is larger than the buffer: $ rsync -FFXHav '--filter=merge global-rsync-filter' Align-37-43/ xxx sending incremental file list *** buffer overflow detected ***: terminated It's in the exclude code in setup_merge_file(): strlcpy(y, save, MAXPATHLEN); Note the 'y' pointer was incremented, so it no longer points to memory with MAXPATHLEN "owned" bytes. Fix it by remembering the number of copied bytes into the 'save' buffer and use that instead of MAXPATHLEN which is clearly incorrect. Fixes #511.
This should be resolved with the merge of #513. |
When
_FORTIFY_SOURCE=2
is enabled during build, rsync crashes. gdb says:How does it come
__glibc_objsize(dirbuf.lto_priv+6)
is less than 4096?https://github.com/WayneD/rsync/blob/2f9b963abaa52e44891180fe6c0d1c2219f6686d/exclude.c#L737
Apparently,
y
can be incremented, so thisMAXPATHLEN
looks to be wrong. That's why.The text was updated successfully, but these errors were encountered: