public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow [not found] <bug-77608-4@http.gcc.gnu.org/bugzilla/> @ 2021-10-13 16:14 ` kees at outflux dot net 2022-01-04 19:56 ` siddhesh at gcc dot gnu.org ` (2 subsequent siblings) 3 siblings, 0 replies; 4+ messages in thread From: kees at outflux dot net @ 2021-10-13 16:14 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608 Kees Cook <kees at outflux dot net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kees at outflux dot net --- Comment #5 from Kees Cook <kees at outflux dot net> --- I think this behavior may, unfortunately, be "as expected", due to how the memcpy overflow checks are working (they're checking surrounding object, yes, like bos(0) would)? The constant-expression bos() calculations do appear to understand the base pointer object, but when faced with "i", it can't know for sure -- it might have room (if "i" is < 3), or not. So it must return -1 as it lacks any other context (like memcpy's "size" argument). There may, however, be a missing opportunity for tightening the memcpy checker? For example: ... volatile unsigned i; struct weird { char a[4]; char b[8]; }; int main (void) { { struct weird instance; char d [3]; P (d + i); memcpy (d + i, "abcdef", 5); // always overflows d (the entire object) i = 7; P (instance.a + i); // can't see into "i" P (instance.a + 7); // room left in instance (5), but not "a" (0) memcpy (instance.a + i, "abcdef", 5); // misses a, doesn't overflow instance. should this warn? __builtin_printf ("%.0s", d); } } -1 -1 0 0 -1 -1 0 0 5 0 5 5 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow [not found] <bug-77608-4@http.gcc.gnu.org/bugzilla/> 2021-10-13 16:14 ` [Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow kees at outflux dot net @ 2022-01-04 19:56 ` siddhesh at gcc dot gnu.org 2022-01-07 4:18 ` siddhesh at gcc dot gnu.org 2022-01-11 14:54 ` siddhesh at gcc dot gnu.org 3 siblings, 0 replies; 4+ messages in thread From: siddhesh at gcc dot gnu.org @ 2022-01-04 19:56 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608 Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |siddhesh at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot gnu.org --- Comment #6 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> --- The volatile causes it to bail out too early because we avoid operating on trees with side effects, but at least without it __bos should be able to detect undefined behaviour. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow [not found] <bug-77608-4@http.gcc.gnu.org/bugzilla/> 2021-10-13 16:14 ` [Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow kees at outflux dot net 2022-01-04 19:56 ` siddhesh at gcc dot gnu.org @ 2022-01-07 4:18 ` siddhesh at gcc dot gnu.org 2022-01-11 14:54 ` siddhesh at gcc dot gnu.org 3 siblings, 0 replies; 4+ messages in thread From: siddhesh at gcc dot gnu.org @ 2022-01-07 4:18 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608 Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #7 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> --- I've posted a patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587698.html which returns the whole size of an object (that's a thing now, since __bos started handling negative offsets) if the offset is not a constant. It goes on top of the dynamic object sizes patchset. Volatile offsets will need more rework (basically delay the side effects check into tree-object-size), so I'll do that after all of these patches are through. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow [not found] <bug-77608-4@http.gcc.gnu.org/bugzilla/> ` (2 preceding siblings ...) 2022-01-07 4:18 ` siddhesh at gcc dot gnu.org @ 2022-01-11 14:54 ` siddhesh at gcc dot gnu.org 3 siblings, 0 replies; 4+ messages in thread From: siddhesh at gcc dot gnu.org @ 2022-01-11 14:54 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608 --- Comment #8 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> --- The test case for pr 103961 exposed a flaw in my patch, where assuming wholesize isn't always safe or at least would need more careful consideration. I need to think this through some more. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-01-11 14:54 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bug-77608-4@http.gcc.gnu.org/bugzilla/> 2021-10-13 16:14 ` [Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow kees at outflux dot net 2022-01-04 19:56 ` siddhesh at gcc dot gnu.org 2022-01-07 4:18 ` siddhesh at gcc dot gnu.org 2022-01-11 14:54 ` siddhesh at gcc dot gnu.org
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).