public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "Vojislav.Tomasevic at Syrmia dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug string/31332] New: Improve detection of buffer overflow at compile-time with FORTIFY_SOURCE Date: Sat, 03 Feb 2024 00:14:05 +0000 [thread overview] Message-ID: <bug-31332-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=31332 Bug ID: 31332 Summary: Improve detection of buffer overflow at compile-time with FORTIFY_SOURCE Product: glibc Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: string Assignee: unassigned at sourceware dot org Reporter: Vojislav.Tomasevic at Syrmia dot com Target Milestone: --- Created attachment 15350 --> https://sourceware.org/bugzilla/attachment.cgi?id=15350&action=edit Test case with buffer overflow in memcpy call FORTIFY_SOURCE currently reports run-time errors when detecting buffer overflows, both with clang and gcc. However, it would be more beneficial to catch the issues earlier (at compile-time), when possible. There is room for improvement in fortified implementations of functions memcpy/memmove/memset/strncpy/bcopy/bzero as buffer overflows can be detected at compile-time and reported as compile-time errors. Consider the example memcpy.c in the attached test case which contains buffer overflow: bash-4.4$ clang -O2 -D_FORTIFY_SOURCE=2 memcpy.c // no compile-time warning bash-4.4$ ./a.out *** buffer overflow detected ***: terminated Aborted (core dumped) Note that the overflow is caught at run-time only. However, in this case, we should be able to detect it at compile-time as both the length and size of the destination pointer is known at compile-time, when compiled with optimizations. With changes to memcpy definition as below, the issue can be caught at compile-time itself. Similar changes could be done to memmove/memset/strncpy/bcopy/bzero functions as well. Both clang and gcc compilers support error/warning attribute, builtin_object_size and builtin_constant_p functions. @@ -26,6 +26,13 @@ __fortify_function void * __NTH (memcpy (void *__restrict __dest, const void *__restrict __src, size_t __len)) { + if (__bos (__dest) != (size_t) -1 + && __builtin_constant_p (__len) + && __len > __bos (__dest)) + { + void __fortify_error (void) __attribute__((error("dest is too small"))); + __fortify_error (); + } return __builtin___memcpy_chk (__dest, __src, __len, __glibc_objsize0 (__dest)); } The above patch could be improved by using _errordecl macro to declare the prototype of the __fortify_error function, which is already used in glibc for similar purposes. If the attached test case is considered now (after applying this patch), there is a compile-time error like the following one: bash-4.4$ clang -O2 -D_FORTIFY_SOURCE=2 memcpy.c In file included from memcpy.c:1: In file included from string.h:535: glibc/install_dir/include/bits/string_fortified.h:34:7: error: call to '__fortify_error' declared with 'error' attribute: dest is too small 34 | __fortify_error (); | ^ 1 error generated. If this is agreeable, I would be interested to work on a patch which improves buffer overflow detection at compile-time. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2024-02-03 0:14 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-03 0:14 Vojislav.Tomasevic at Syrmia dot com [this message] 2024-02-03 13:38 ` [Bug string/31332] " schwab@linux-m68k.org 2024-02-03 13:40 ` sam at gentoo dot org 2024-02-05 15:07 ` fweimer at redhat dot com 2024-02-05 15:08 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-31332-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).