https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118095
--- Comment #4 from Kees Cook ---
I've added Martin to CC. :) Martin, you wrote this code originally; do you have
a moment to look at how this might best be solved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118095
--- Comment #3 from Kees Cook ---
(In reply to uecker from comment #1)
> I think you may also need to adapt get_attr_nonstring_decl
How do I walk "up" a tree to see if it is part of a multidimensional array? I
don't understand what is happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #22 from Kees Cook ---
On a related note, I need to be able to apply nonstring to arrays of char
arrays. See bug #118095.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118095
Bug ID: 118095
Summary: nonstring attribute cannot be applied to array of char
arrays
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #21 from Kees Cook ---
Okay, now with tests and an updated truncation message. :)
Please see:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671714.html
(Hopefully I have managed to get coding and commit log style correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #19 from Kees Cook ---
Created attachment 59874
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59874&action=edit
RFC for ignoring NUL byte with nonstring attribute
Here's an RFC patch for allowing the NUL char truncation when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
Bug 69698 depends on bug 92589, which changed state.
Bug 92589 Summary: heuristic to avoid flexible array members too liberal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589
Kees Cook changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
--- Comment #7 from Kees Cook ---
Could "nonstring" be applied to string literals? (Like the "u" suffix idea, but
this would be more backward-compatible.) For example, from the example in
comment #1:
{ "BOOP", ... }
becomes:
{ "BOOT" __attr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178
Bug ID: 117178
Summary: -Wunterminated-string-initialization should ignore
trailing NUL byte for nonstring char arrays
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #4 from Kees Cook ---
This feature is designed as a "security through obscurity" feature that has
real-world benefits to specialized high-security deployments where performance
is not a concern.
It is never expected to be compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116984
Kees Cook changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116984
--- Comment #5 from Kees Cook ---
(In reply to Kees Cook from comment #0)
> It should be be possible to trigger -fsanitize=bounds within
> __builtin_dynamoc_object_size() (which should have no side-effects).
Ugh typo. I meant "It should *not* b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116984
--- Comment #4 from Kees Cook ---
(In reply to Andrew Pinski from comment #1)
> I don't think so since &p->array[negative] is undefined behavior even inside
> a dynamic boz.
Without counted_by, that is true. With counted_by all out of bounds
ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116984
Bug ID: 116984
Summary: -fsanitize=bounds triggers within
__builtin_dynamic_object_size()
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116983
Bug ID: 116983
Summary: counted_by not used to identify singleton pointers
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #65 from Kees Cook ---
(In reply to Alejandro Colomar from comment #64)
> How about having two macros? One that works for non-attributed pointers,
> and other that works for attributed ones. And use the appropriate one for
> each o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #63 from Kees Cook ---
(In reply to Alejandro Colomar from comment #62)
> What's the value of returning NULL instead of just failing the compilation
> with an error?
It's so that the same allocator macros can be used for FAM structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #59 from Kees Cook ---
(In reply to Bill Wendling from comment #57)
> (In reply to Kees Cook from comment #47)
> > So, with the builtin being used within the allocator to set counter, now the
> > old code pattern still works (as coun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #55 from Kees Cook ---
(In reply to Alejandro Colomar from comment #49)
> For reading the counted_by value, that is, for reading the number of
> elements in the FAM, I'm implementing a __lengthof__ operator, which returns
> the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #47 from Kees Cook ---
Yes, the counter must be manually set until Linux minimum compiler versions are
raised to include counted_by support, but this is about making the transition
to using counted_by easier and less prone to bugs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #32 from Kees Cook ---
(In reply to qinzhao from comment #29)
> (In reply to Jakub Jelinek from comment #28)
> > Speaking of counted_by, I see support for it in c-family/ and c/, but not in
> > cp/ at all, what is the attribute suppo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #31 from Kees Cook ---
(In reply to Qing Zhao from comment #25)
> The source code need to be:
>
> If (__builtin_get_counted_by (P->FAM))
> __builtin_get_counted_by (P->FAM) = COUNT;
>
> Yes, I agree that this is good too for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #1 from Kees Cook ---
Matching Clang feature request:
https://github.com/llvm/llvm-project/issues/99774
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
Bug ID: 116016
Summary: enhancement: add __builtin_set_counted_by(P->FAM,
COUNT) or equivalent
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #8 from Kees Cook ---
The warning is about:
val = &sg->vals[index];
poc.c:20:20: warning: array subscript 4 is above array bounds of 'int[4]'
[-Warray-bounds=]
20 | val = &sg->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. T
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 ple
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
Pr
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 wi
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: unk
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
Severity
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 -fno-strict-o
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 /dev/n
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.
Totally
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
Component
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 elim
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)?
It'
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 co
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 impr
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
> extension.
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 followin
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: arra
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
Component
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 ha
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
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #30 from
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) {
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104504
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #1 from
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: tar
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 wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Kees Cook changed:
What|Removed |Added
CC||kees at outflux dot net
--- Comment #3 from
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 som
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
Component
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
tra
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
__builtin_object_size(
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&action=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
S
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
86 matches
Mail list logo
