Bug 705790
| Summary: | memcpy/memmove read out of bounds | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dan Winship <danw> | ||||
| Component: | valgrind | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 15 | CC: | caolanm, dodji, jakub, schwab | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | valgrind-3.6.1-4.fc15 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-06-24 03:40:09 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Dan Winship
2011-05-18 13:33:20 UTC
This is a false positive, the address is correctly aligned. I'm pretty sure it's not claiming incorrect alignment, it's claiming that glibc is doing an (aligned) 8-byte read when there are only 7 bytes left in the buffer, and so it is reading 1 byte beyond the end of the buffer. There is nothing wrong in reading that 1 byte beyond the end of the buffer, if you know the read won't trap because of that and if you don't actualy use it. valgrind overrides glibc's memmove (and many other functions) though, so it is strange that glibc memmove has been called. Created attachment 503686 [details]
seward suggests this as a quick-fix to make valgrind usable again
I don't think the patch is correct, after all there are 3 different memmove implementations. As it worked in F14 and valgrind already has IFUNC support, I bet this is related to the glibc workaround for lame apps. readelf -Ws /lib64/libc.so.6 | grep 'memcpy\|memmove' | grep -v 'LOCAL\|wmem\|_chk' 1103: 00000035e7a83160 71 IFUNC GLOBAL DEFAULT 12 memcpy.5 1104: 00000035e7a88d40 60 IFUNC GLOBAL DEFAULT 12 memcpy@@GLIBC_2.14 1944: 00000035e7a83160 71 IFUNC GLOBAL DEFAULT 12 memmove@@GLIBC_2.2.5 5575: 00000035e7a83160 71 IFUNC GLOBAL DEFAULT 12 memcpy.5 6284: 00000035e7a83160 71 IFUNC GLOBAL DEFAULT 12 memmove 7443: 00000035e7a88d40 60 IFUNC GLOBAL DEFAULT 12 memcpy@@GLIBC_2.14 shows that in glibc 2.14+ memcpy.5 is IFUNC aliased to memmove, while memcpy@@GLIBC_2.14 is a real memcpy (again, IFUNC). Well, we could stick in the other two implementation too. The crucial bit for me is that locally I get sane useful results out of valgrind again. Please try rawhide valgrind (3.6.1-4.fc16), if that works, will build the same for f15 updates-testing too. valgrind-3.6.1-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/valgrind-3.6.1-4.fc15 Package valgrind-3.6.1-4.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing valgrind-3.6.1-4.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/valgrind-3.6.1-4.fc15 then log in and leave karma (feedback). It solves that. I do however get new warnings of... ==6241== Conditional jump or move depends on uninitialised value(s) ==6241== at 0x3771217476: index (strchr.S:56) ==6241== by 0x37712078F2: expand_dynamic_string_token (dl-load.c:326) ==6241== by 0x3771208241: _dl_map_object (dl-load.c:2193) ==6241== by 0x37712017DD: map_doit (rtld.c:629) ==6241== by 0x377120E8A5: _dl_catch_error (dl-error.c:178) ==6241== by 0x3771200F16: do_preload (rtld.c:813) ==6241== by 0x37712048A0: dl_main (rtld.c:1696) ==6241== by 0x3771214F83: _dl_sysdep_start (dl-sysdep.c:244) ==6241== by 0x377120512E: _dl_start (rtld.c:334) ==6241== by 0x3771201607: ??? (in /lib64/ld-2.13.90.so) ==6241== by 0x1: ??? ==6241== by 0x7FEFFD496: ??? ==6241== by 0x7FEFFD4BA: ??? ==6241== ==6241== Conditional jump or move depends on uninitialised value(s) ==6241== at 0x377121747B: index (strchr.S:59) ==6241== by 0x37712078F2: expand_dynamic_string_token (dl-load.c:326) ==6241== by 0x3771208241: _dl_map_object (dl-load.c:2193) ==6241== by 0x37712017DD: map_doit (rtld.c:629) ==6241== by 0x377120E8A5: _dl_catch_error (dl-error.c:178) ==6241== by 0x3771200F16: do_preload (rtld.c:813) ==6241== by 0x37712048A0: dl_main (rtld.c:1696) ==6241== by 0x3771214F83: _dl_sysdep_start (dl-sysdep.c:244) ==6241== by 0x377120512E: _dl_start (rtld.c:334) ==6241== by 0x3771201607: ??? (in /lib64/ld-2.13.90.so) ==6241== by 0x1: ??? ==6241== by 0x7FEFFD496: ??? ==6241== by 0x7FEFFD4BA: ??? Forgotten yum update? F14 now has glibc-2.14, instead of glibc-2.13.90. Ah, indeed. Yup, noiseless now. valgrind-3.6.1-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. |