I noticed that running rpm 4.17.1.1 (no patches, upstream sources) under valgrind when built on tumbleweed gives valgrind errors like: 


==21993== Command: ./rpmbuild -bp /home/dirk/rpmbuild/SOURCES/libavif.spec
==21993== 
==21993== Source and destination overlap in memcpy_chk(0x574a904, 0x574a900, 20)
==21993==    at 0x484E302: __memcpy_chk (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==21993==    by 0x43B674: memmove (string_fortified.h:36)
==21993==    by 0x43B674: rpmdsMerge (rpmds.c:868)
==21993==    by 0x418B3F: addReqProv (reqprov.c:37)
==21993==    by 0x418B78: addReqProvPkg (reqprov.c:48)
==21993==    by 0x4162C4: parseRCPOT (parseReqs.c:321)
==21993==    by 0x41516C: handlePreambleTag (parsePreamble.c:903)
==21993==    by 0x41516C: parsePreamble (parsePreamble.c:1161)
==21993==    by 0x418092: parseSpec (parseSpec.c:927)
==21993==    by 0x4093BC: buildForTarget.constprop.0 (rpmbuild.c:491)
==21993==    by 0x4096B2: build.constprop.0 (rpmbuild.c:528)
==21993==    by 0x40899F: main (rpmbuild.c:690)
==21993== 


as you can see in the sourcecode, it calls memmove(), but somehow that gets mapped to memcpy_check(). the string_fortified.h:36 looks like this: 

__fortify_function void *
__NTH (memmove (void *__dest, const void *__src, size_t __len))
{
  return __builtin___memmove_chk (__dest, __src, __len,
                                  __glibc_objsize0 (__dest));
}


reproducer:

tar xf rpm-4.17.1.1.tar.bz2
cd rpm-4.17.1.1
CFLAGS="-D_FORTIFY_SOURCE=3  -g -O2 -Wall" ./configure --enable-static --disable-shared --disable-sqlite --prefix=/usr --with-vendor=suse --with-rundir=/run --without-archive --libdir=/usr/lib64
make -j ; make rpmbuild
valgrind ./rpmbuild -bp ~/rpmbuild/SOURCES/libavif.spec 

the last is just to execute %prep, aka parsing a spec file. from my experience any spec file triggers the problem. 

the issue goes way with -D_FORTIFY_SOURCE=2 or lower interestingly.