The following code snippet, compiled with -Os -fstack-protector: #include <string.h>
int StringChecksum(char *s) { char buffer[2048]; int i; int checksum = 0; memset(buffer, 0, 2048); strcpy(buffer, s); for (i=0; i<2048; i++) checksum += buffer[i]; return checksum; } leads to the following snippet of assembly for the part where gcc puts the canary value on the stack: (part of the full assembly of the function) movq %rsp, %rdi movq %fs:40, %rax movq %rax, 2056(%rsp) xorl %eax, %eax call memset the key instruction for this bug is the "xorl %eax, %eax". The intent of that instruction seems to be to not leak the canary value into the actual function code; however the canary value is 64 bits and in RAX, while the XOR is only zeroing the lower 32 bits. For consistency and information security, this XOR should, I think, clear all of RAX (which is same-cost anyway both in size and execution) -- Summary: -fstack-protector leaks the upper bits of RAX Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjan at linux dot intel dot com GCC host triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457