This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] handle non-constant offsets in -Wstringop-overflow (PR 77608)


On 11/18/2017 12:53 AM, Jeff Law wrote:
On 11/17/2017 12:36 PM, Martin Sebor wrote:
The attached patch enhances -Wstringop-overflow to detect more
instances of buffer overflow at compile time by handling non-
constant offsets into the destination object that are known to
be in some range.  The solution could be improved by handling
even more cases (e.g., anti-ranges or offsets relative to
pointers beyond the beginning of an object) but it's a start.

I should have made it even more clear that this change affects
just warnings, not the runtime protection with _FORTIFY_SOURCE.
The latter is driven by the __builtin_object_size intrinsic and
by the compute_builtin_object_size GCC function.

This patch does not change what __builtin_object_size returns.

In addition to bootsrapping/regtesting GCC, also tested with
Binutils/GDB, Glibc, and the Linux kernel on x86_64 with no
regressions.

Martin

The top of GDB fails to compile at the moment so the validation
there was incomplete.

gcc-77608.diff


PR middle-end/77608 - missing protection on trivially detectable runtime buffer overflow

gcc/ChangeLog:

	PR middle-end/77608
	* builtins.c (compute_objsize): Handle non-constant offsets.

gcc/testsuite/ChangeLog:

	PR middle-end/77608
	* gcc.dg/Wstringop-overflow.c: New test.
The recursive call into compute_objsize passing in the ostype avoids
having to think about the whole object vs nearest containing object
issues.  Right?

Yes, something like that.

What's left to worry about is maximum or minimum remaining bytes in the
object.  At least that's my understanding of how ostype works here.

-Wstringop-overflow (i.e., warnings only) always uses the largest
object size for memxxx functions (type 0) and the smallest (type
2) for string functions by default.  This can be changed but I
suspect no one does because (IME) few users understand what
the other modes mean or what good using them vs the default might
do.  It was probably a mistake to expose the mode via the option.

I'll address the remaining comments separately.

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]