One false positive fixed in 3.21.0 (in Fedora/RHEL) was the false positive of memmove seen as memcpy with overlapping source and destination buffers (this is a real issue for memcpy, but not for memmove). We missed the case of the false positive of __memmove_chk seen as __memcpy_chk (which are used with _FORTIFY_SOURCE=2).

This is somewhat tricky to trigger because it depends on how valgrind does symbol resolution and whether memmove and memcpy (or their _chk variants) are implemented through ifuncs using the same code (address).

The following shows the issue though:

$ cat c.c 
#include <stdio.h>
#include <string.h>

volatile char *s;

char *
__memcpy_chk(char *d, const char *s, size_t n, size_t dn);

char *
__memmove_chk(char *d, const char *s, size_t n, size_t dn);

int main(int argc,const char *argv[])
{	
	char buffer[100];
	__memcpy_chk(buffer, &buffer[20], 9, 100);
	__memmove_chk(buffer, &buffer[1], 99, 100);
	return 0;
}
$ gcc -g -o c c.c
[ignore the valid warnings]
$ valgrind -q ./c
==1062238== Source and destination overlap in memcpy_chk(0x1ffefff8a0, 0x1ffefff8a1, 99)
==1062238==    at 0x484C862: __memcpy_chk (vg_replace_strmem.c:1743)
==1062238==    by 0x401180: main (c.c:16)
==1062238== 

Note that line 16 is the __memmove_chk call (not the __memcpy_chk one).
This shouldn't produce an overlap warning (because memmove is allowed to work on overlapping source and destination buffers).

The workaround is just removing 2 lines as outlined in the upstream bug report. The workaround is already in Fedora.