Control: tags -1 -moreinfo

On Sat, Feb 16, 2019 at 12:26:36AM +0100, Chris Lamb wrote:
> I will thus leave this bug as "moreinfo" awaiting input from others.

What's presumably happening here is that the size of the destination
buffer and size of the copy are known, so it's clear at compile time
that the compile can't overflow.

E.g.:

$ cat wmemcpy-test.cc
#include <wchar.h>

wchar_t buf[10];
void f(const wchar_t* p, int n) {
#ifdef FIXED_LENGTH
    (void)n;
    wmemcpy(buf, p, 6);
#else
    wmemcpy(buf, p, n);
#endif
}
$ g++ -Wall -W -D_FORTIFY_SOURCE=2 -O2 -S wmemcpy-test.cc -o -
        .file   "wmemcpy-test.cc"
        .text
        .p2align 4
        .globl  _Z1fPKwi
        .type   _Z1fPKwi, @function
_Z1fPKwi:
.LFB26:
        .cfi_startproc
        movslq  %esi, %rdx
        movl    $10, %ecx
        movq    %rdi, %rsi
        leaq    buf(%rip), %rdi
        jmp     __wmemcpy_chk@PLT
        .cfi_endproc
.LFE26:
        .size   _Z1fPKwi, .-_Z1fPKwi
        .globl  buf
        .bss
        .align 32
        .type   buf, @object
        .size   buf, 40
buf:
        .zero   40
        .ident  "GCC: (Debian 9.2.1-8) 9.2.1 20190909"
        .section        .note.GNU-stack,"",@progbits

But if the lengths are both known:

$ g++ -Wall -W -D_FORTIFY_SOURCE=2 -DFIXED_LENGTH -O2 -S wmemcpy-test.cc -o -
        .file   "wmemcpy-test.cc"
        .text
        .p2align 4
        .globl  _Z1fPKwi
        .type   _Z1fPKwi, @function
_Z1fPKwi:
.LFB26:
        .cfi_startproc
        movq    %rdi, %rsi
        movl    $6, %edx
        leaq    buf(%rip), %rdi
        jmp     wmemcpy@PLT
        .cfi_endproc
.LFE26:
        .size   _Z1fPKwi, .-_Z1fPKwi
        .globl  buf
        .bss
        .align 32
        .type   buf, @object
        .size   buf, 40
buf:
        .zero   40
        .ident  "GCC: (Debian 9.2.1-8) 9.2.1 20190909"
        .section        .note.GNU-stack,"",@progbits

The key difference here is:

<       jmp     __wmemcpy_chk@PLT
---
>       jmp     wmemcpy@PLT

The same issue applies to memcpy() which is why it's deliberately from
lintian's list:

https://sources.debian.org/src/lintian/2.31.0/data/binaries/hardened-functions/?hl=6#L6
 

Presumably wmemcpy() is simply much less widely used than memcpy(), and
that's the only reason it's not also omitted already.

Cheers,
    Olly

Reply via email to