Bug#921136: lintian: hardening-no-fortify-functions possible false positive
- To: Chris Lamb <lamby@debian.org>, 921136@bugs.debian.org
- Cc: Scott Talbert <swt@techie.net>
- Subject: Bug#921136: lintian: hardening-no-fortify-functions possible false positive
- From: Olly Betts <olly@survex.com>
- Date: Wed, 30 Oct 2019 13:45:45 +1300
- Message-id: <[🔎] 20191030004545.GA9526@survex.com>
- Reply-to: Olly Betts <olly@survex.com>, 921136@bugs.debian.org
- In-reply-to: <1550273196.214293.1658898504.31B6E04D@webmail.messagingengine.com>
- References: <154906928565.26456.6049876583145738097.reportbug@debian-unstable.techie.net> <1550061170.2486994.1657127312.441A5331@webmail.messagingengine.com> <alpine.DEB.2.21.1902131924230.2111@bear.techie.net> <154906928565.26456.6049876583145738097.reportbug@debian-unstable.techie.net> <1550273196.214293.1658898504.31B6E04D@webmail.messagingengine.com> <154906928565.26456.6049876583145738097.reportbug@debian-unstable.techie.net>
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 to: