rsync - Feb 2024 - rsync segfaults when openssl fips is enabled

Hi All,

Copying the content from the GH issue as is.
Need your inputs on the same.
FWIW, the coredump files generated in linux have xattr values which are >
32 bytes.

https://github.com/WayneD/rsync/issues/569

Hi All,

System details:

root at ph3dev [ ~ ]# rsync --version
rsync  version 3.2.4  protocol version 31
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, symlinks, symtimes, hardlinks, hardlink-specials,
    hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, no ACLs,
    xattrs, optional protect-args, iconv, prealloc, stop-at, no
crtimesOptimizations:
    SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
Checksum list:
    xxh128 xxh3 xxh64 (xxhash) md5 md4 none
Compress list:
    zstd lz4 zlibx zlib none

OS:
Photon OS 3.0 with openssl fips enabled

I'm using rsync like below:

rsync -arXHpvxog <src> <dest>

While doing so, if any file in src or dest location has a xattr value
which is more than 32 bytes long, rsync segfaults.

root at ph3dev [ ~ ]# getfattr -d -m '' -- /opt/x
getfattr: Removing leading '/' from absolute path names
# file: opt/x
user.bla1="1234567890abcdef1234567890abcdef1" --------> 33 bytes
long

After examining the coredump file, this happens at;

rsync/xattrs.c
Line 277 in 2f9b963

sum_init(xattr_sum_nni, checksum_seed);

Here md5 is used by default and md5 usage is prohibited in fips mode.

Is there any way to workaround this problem? Also, why not use xxhash
for this operation like it's used by default during --checksum option.

-- 
Shedi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20240221/2f9bf188/attachment.htm>

Hi All,

Any inputs on this issue?

--
Shedi


On Wed, Feb 21, 2024 at 5:12?PM Shreenidhi Shedi <
shreenidhi.shedi at broadcom.com> wrote:
> Hi All,
>
> Copying the content from the GH issue as is.
> Need your inputs on the same.
> FWIW, the coredump files generated in linux have xattr values which are
>
> 32 bytes.
>
> https://github.com/WayneD/rsync/issues/569
>
> Hi All,
>
> System details:
>
> root at ph3dev [ ~ ]# rsync --version
> rsync  version 3.2.4  protocol version 31
> Capabilities:
>     64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
>     socketpairs, symlinks, symtimes, hardlinks, hardlink-specials,
>     hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, no ACLs,
>     xattrs, optional protect-args, iconv, prealloc, stop-at, no
crtimesOptimizations:
>     SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
> Checksum list:
>     xxh128 xxh3 xxh64 (xxhash) md5 md4 none
> Compress list:
>     zstd lz4 zlibx zlib none
>
> OS:
> Photon OS 3.0 with openssl fips enabled
>
> I'm using rsync like below:
>
> rsync -arXHpvxog <src> <dest>
>
> While doing so, if any file in src or dest location has a xattr value which
is more than 32 bytes long, rsync segfaults.
>
> root at ph3dev [ ~ ]# getfattr -d -m '' -- /opt/x
> getfattr: Removing leading '/' from absolute path names
> # file: opt/x
> user.bla1="1234567890abcdef1234567890abcdef1" --------> 33
bytes long
>
> After examining the coredump file, this happens at;
>
> rsync/xattrs.c
> Line 277 in 2f9b963
>
> sum_init(xattr_sum_nni, checksum_seed);
>
> Here md5 is used by default and md5 usage is prohibited in fips mode.
>
> Is there any way to workaround this problem? Also, why not use xxhash for
this operation like it's used by default during --checksum option.
>
> --
> Shedi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20240312/4838457f/attachment.htm>