https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #8 from Kees Cook ---
The warning is about:
val = >vals[index];
poc.c:20:20: warning: array subscript 4 is above array bounds of 'int[4]'
[-Warray-bounds=]
20 | val = >vals[index];
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #6 from Kees Cook ---
(In reply to qinzhao from comment #5)
> adding __attribute__ ((noreturn)) to the routine "warn" can eliminate the
> false positive warning.
But it does return... it's not an assert.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #8 from Kees Cook ---
Clang bug: https://github.com/llvm/llvm-project/issues/84565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #7 from Kees Cook ---
There is still no way to use C99 flexible arrays in unions (or alone in
structs) without syntactic obfuscation. The extension that already allows
0-sized arrays in unions should be extended to cover C99 arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
Kees Cook changed:
What|Removed |Added
CC||carlos at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #42 from Kees Cook ---
Exciting! Are you able to attach the latest patch? I'd love to try it out. I've
been testing Clang's version as well:
https://reviews.llvm.org/D148381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #3 from Kees Cook ---
Is there a viable path to a solution here? This seems to cause enough false
positives with -Warray-bounds that at least Linux can't enable the flag. I'd
really like to have it enabled, though, since it finds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
Bug ID: 109071
Summary: -Warray-bounds warning when array index checked via
inline
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #6 from Kees Cook ---
I really want to avoid the changes to sizeof() -- this will confuse a lot of
other things. Sizeof is expected to be a constant expression, for example.
I think the attribute is best since it avoids colliding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #1 from Kees Cook ---
The corresponding Clang feature request is here:
https://github.com/llvm/llvm-project/issues/60928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
Bug ID: 108896
Summary: provide "element_count" attribute to give more context
to __builtin_dynamic_object_size() and
-fsanitize=bounds
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
Kees Cook changed:
What|Removed |Added
Attachment #54508|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #1 from Kees Cook ---
The matching Clang bug is: https://github.com/llvm/llvm-project/issues/60926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
Bug ID: 108894
Summary: -fsanitize=bounds missing bounds provided by
__builtin_dynamic_object_size()
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #7 from Kees Cook ---
(In reply to Kees Cook from comment #6)
> Sorry, I forgot to include those details fully! Here's how I'm seeing it:
>
> $ gcc --version
> gcc (GCC) 13.0.0 20230105 (experimental)
> ...
> $ gcc -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #6 from Kees Cook ---
Sorry, I forgot to include those details fully! Here's how I'm seeing it:
$ gcc --version
gcc (GCC) 13.0.0 20230105 (experimental)
...
$ gcc -O2 -fno-strict-overflow -fsanitize=shift -Warray-bounds -c -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Kees Cook changed:
What|Removed |Added
Attachment #54198|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #2 from Kees Cook ---
Ugh, sorry. The PoC is bad -- the bounds check isn't present. Let me try to get
a another PoC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Kees Cook changed:
What|Removed |Added
CC||arnd at linaro dot org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Bug ID: 108306
Summary: false-positive -Warray-bounds warning emitted with
-fsanitize=shift
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #11 from Kees Cook ---
(In reply to Richard Biener from comment #10)
> I sofar refrained from doing this because of the large amount of fallout and
> followup changes and I think those are not warranted on the GCC 12 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
Kees Cook changed:
What|Removed |Added
CC||qing.zhao at oracle dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107162
Bug ID: 107162
Summary: -Wmisleading-indentation is blinded by comments
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #6 from Kees Cook ---
(In reply to Richard Biener from comment #5)
> Should be fixed on trunk. Can you check on the original unreduced testcase?
Thanks! I've done test builds and can confirm these two false positives have
been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #41 from Kees Cook ---
(In reply to Bill Wendling from comment #40)
> The question then is if `-fstrict-flex-arrays=3' is used, what does a `[0]'
> at the end of a struct represent (assuming GCC no longer treats it as an
> FAM)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #34 from Kees Cook ---
-fstrict-flex-arrays=3 is still needed. (E.g. for proper FORTIFY coverage,
etc.) I don't have an opinion about the -W options, though.(In reply to James Y
Knight from comment #33)
> (In reply to qinzhao from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #21 from Kees Cook ---
(In reply to Martin Sebor from comment #20)
> Well, I just "asked" for such an option the same way you asked for
> -fstrict-flex-arrays in comment #3, because I believe it would be useful to
> make the BOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #19 from Kees Cook ---
(In reply to Martin Sebor from comment #18)
> The zero size case exists (and is documented) solely as a substitute for
> flexible array members. Treating is as an ordinary array would disable that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #17 from Kees Cook ---
(In reply to qinzhao from comment #16)
> additional work are needed in order to make this task complete:
>
> 1. add one more new gcc option:
>
> -fstrict-flex-arrays
>
> when it's on, only treat the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #13 from Kees Cook ---
Maybe the enum needs to also be expanded so that [0] can be distinguished from
[]?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #11 from Kees Cook ---
and with a flex array to compare:
https://godbolt.org/z/s9nb4Y7q4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #10 from Kees Cook ---
Here's a slightly reworked example:
https://godbolt.org/z/EvehMax84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #9 from Kees Cook ---
Just to clarify, __builtin_dynamic_object_size() shouldn't have anything to do
with this. What's needed is something like -fstrict-flex-arrays so that all the
"trailing array is a flex array" assumptions can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #1 from Kees Cook ---
The Linux kernel has encountered at least two of these (seen as specifically
"array subscript 32", though the root cause may be causing many others:
../drivers/net/wireless/ath/ath9k/mac.c:373:22: warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
Bug ID: 105679
Summary: erroneous -Warray-bounds warning with sanitizer
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #7 from Kees Cook ---
Right, perhaps I should rename this bug? The much more surprising thing is the
lack of warning about the uninit use. With or without -ftrivial-auto-var-init,
I'd want to have the diagnostic that a UB may have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #2 from Kees Cook ---
https://godbolt.org/z/99Pdro9Te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
--- Comment #1 from Kees Cook ---
(Also this doesn't warn about y being used uninitialized.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
Bug ID: 105539
Summary: -ftrivial-auto-var-init=zero happening too late?
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #4 from Kees Cook ---
The kernel keeps gaining more of these cases, so it'll be important to get this
fixed:
https://lore.kernel.org/lkml/200fe5cb203ad5cc00c5c60b7ded2cd85c9b85ea.ca...@perches.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
--- Comment #4 from Kees Cook ---
(Ah, I knew this had been reported before. I found it now...)
Duplicate of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
--- Comment #2 from Kees Cook ---
As mentioned in a Linux kernel thread, isn't it possible to transform this:
switch (x) {
int y;
default:
y = x * 2;
return y;
}
into this:
{
int y;
switch (x) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428
--- Comment #2 from Kees Cook ---
Note that this needs a struct attribute that will allow structs to be excluded
from the diagnostic (since the kernel needs to deal with legacy UAPI headers
forever).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #11 from Kees Cook ---
The trouble with "optimize" is that it just doesn't work. The kernel has banned
its use because it results in all other optimization options being forgotten
for the function in question.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102352
Bug ID: 102352
Summary: Add -mstack-protector-guard=... for arm32
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #9 from Kees Cook ---
(In reply to Jakub Jelinek from comment #8)
> So, instead (when building the kernel with sanitization) build with
> -fsanitize=signed-integer-overflow and no -fno-strict-overflow, and
> the routines where you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #7 from Kees Cook ---
The problem the kernel needs to solve is basically having our cake and eating
it too. :)
In _most_ situations, we want signed overflows to trap (i.e. get caught by
"-fsanitize=signed-integer-overflow").
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
Bug ID: 101891
Summary: Adjust -fzero-call-used-regs to always use XOR
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #3 from Kees Cook ---
Eww. That means _FORTIFY_SOURCE doesn't work correctly.
Can there please be a -fstrict-flex-arrays or something to turn off all the
heuristics so a code base can declare it only uses flex arrays for dynamic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
Bug ID: 101836
Summary: __builtin_object_size(P->M, 1) where M is an array and
the last member of a struct fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #5 from Kees Cook ---
Perhaps the best question to ask is "given an arbitrary argument, how can code
detect the remaining bytes of a member, including if the member contains a
flexible array?"
Because right now, this does not work:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #4 from Kees Cook ---
It seems like this isn't about crossing field boundaries -- it's asking "how
large is this particular member?" and bos can't know the answer because there
is a flex-array.
Why would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #2 from Kees Cook ---
Created attachment 51280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51280=edit
Same PoC, but with malloc to provide non-unlimited bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #1 from Kees Cook ---
This is even more visible when the size IS known (via malloc hinting, for
example):
https://godbolt.org/z/4v5rKbhaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
Bug ID: 101832
Summary: __builtin_object_size(P->M, 1) where M ends with a
flex-array behaves like sizeof()
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
Bug ID: 101419
Summary: collapsing memset() calls can break
__builtin_object_size()
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
61 matches
Mail list logo
