Mailing List Archive

Hi Arjen,

I see what you're talking about. It is a little confounding. We have a valgrind suppression rule for this specific issue: https://github.com/Cisco-Talos/clamav-devel/commit/8cfec0b245abfac9564c11012d67b19da004e927

{
binhex-overlapping-memmove
Memcheck:Overlap
fun:__memcpy_chk
fun:memmove
fun:cli_binhex
...
}

Your stack trace has "UnknownInlinedFun " instead of "memmove", which is ... odd. I suppose feel free to ignore the FP. Adding another suppression rule with "UnknownInlinedFun" in it doesn't feel good, nor does spending the effort to reimplement without overlapping memmoves. Thoughts?

-Micah


-----Original Message-----
From: clamav-users <clamav-users-bounces@lists.clamav.net> On Behalf Of Arjen de Korte via clamav-users
Sent: Friday, September 18, 2020 11:36 AM
To: clamav-users@lists.clamav.net
Cc: Arjen de Korte <build+clamav@de-korte.org>
Subject: [clamav-users] False positive (?) in check6_clamd_vg test

Three of the four valgring tests fail, with what seems to be false positives:

==18703== ERROR SUMMARY: 12 errors from 1 contexts (suppressed: 0 from 0) ==18703== ==18703== 12 errors in context 1 of 1:
==18703== Source and destination overlap in memcpy_chk(0x1ffeffd1e0, 0x1ffeffd1fe, 549)
==18703== at 0x48405C2: __memcpy_chk (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18703== by 0x4A764A7: UnknownInlinedFun (string_fortified.h:40)
==18703== by 0x4A764A7: cli_binhex (binhex.c:106)
==18703== by 0x4A33CA6: cli_magic_scan (scanners.c:4159)
==18703== by 0x4A2F2F2: UnknownInlinedFun (scanners.c:4597)
==18703== by 0x4A2F2F2: cli_magic_scan_nested_fmap_type (scanners.c:4679)
==18703== by 0x4A37835: scan_common (scanners.c:4854)
==18703== by 0x4A38003: cl_scandesc_callback (scanners.c:5023)
==18703== by 0x4A380AA: cl_scandesc (scanners.c:4549)
==18703== by 0x1148F6: test_cl_scandesc_fn (check_clamav.c:181)
==18703== by 0x4BF5F50: ??? (in /usr/lib64/libcheck.so.0.0.0)
==18703== by 0x4BF68C9: srunner_run_tagged (in
/usr/lib64/libcheck.so.0.0.0)
==18703== by 0x113F02: main (check_clamav.c:1385)
==18703==
==18703== ERROR SUMMARY: 12 errors from 1 contexts (suppressed: 0 from 0)

The sources leading up to this show that ClamAV is using 'memmove'
(which is safe with overlapping source and destination):

libclamav/binhex.c
104 reslen = 0;
105 cli_dbgmsg("cli_binhex: decoding '%s' - %u
bytes of data to %s - %u bytes or resources to %s\n", decoded + 1, datalen, dname, reslen, rname);
106 memmove(decoded, &decoded[hdrlen], dec_done - hdrlen);
107 dec_done -= hdrlen;
108 write_phase++;

/usr/include/bits/string_fortified.h
37 __fortify_function void *
38 __NTH (memmove (void *__dest, const void *__src, size_t __len))
39 {
40 return __builtin___memmove_chk (__dest, __src, __len,
__bos0 (__dest));
41 }

But somehow valgrind considers this as a call to 'memcpy' (which is not guaranteed to be safe with overlapping source and destination).
How to proceed from here?






_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Citeren "Micah Snyder (micasnyd)" <micasnyd@cisco.com>:

> Hi Arjen,
>
> I see what you're talking about. It is a little confounding. We
> have a valgrind suppression rule for this specific issue:
> https://github.com/Cisco-Talos/clamav-devel/commit/8cfec0b245abfac9564c11012d67b19da004e927
>
> {
> binhex-overlapping-memmove
> Memcheck:Overlap
> fun:__memcpy_chk
> fun:memmove
> fun:cli_binhex
> ...
> }
>
> Your stack trace has "UnknownInlinedFun " instead of "memmove",
> which is ... odd. I suppose feel free to ignore the FP. Adding
> another suppression rule with "UnknownInlinedFun" in it doesn't feel
> good, nor does spending the effort to reimplement without
> overlapping memmoves. Thoughts?

Yup. Your mention of the weird "UnknownInlinedFun " tipped me off. We
use LTO by default in openSUSE Tumbleweed and that seems to be the
culprit here. Without LTO, the valgrind tests are OK. Apparently LTO
strips symbols that are needed for valgrind to see what is going on.
Thanks!


_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml