| Age | Commit message (Collapse) | Author |
|---|
|
Fixing the following issue:
```
In file included from xstrndup.c:34:
/OpenWrt/aarch64/staging_dir/toolchain-aarch64_cortex-a53_gcc-14.3.0_musl/include/fortify/string.h: In function 'mempcpy':
/OpenWrt/aarch64/staging_dir/toolchain-aarch64_cortex-a53_gcc-14.3.0_musl/include/fortify/string.h:340:13: error: 'nonnull' argument '__d' compared to NULL [-Werror=nonnull-compare]
340 | if (!__d || !__s)
| ^~~~
/OpenWrt/aarch64/staging_dir/toolchain-aarch64_cortex-a53_gcc-14.3.0_musl/include/fortify/string.h:340:21: error: 'nonnull' argument '__s' compared to NULL [-Werror=nonnull-compare]
340 | if (!__d || !__s)
| ^~~~
cc1: all warnings being treated as errors
make[5]: *** [Makefile:511: xstrndup.o] Error 1
```
Reported in https://github.com/openwrt/openwrt/pull/20552
|
|
|
|
The previews code tried to get the value defined for
FORTIFY_USE_NATIVE_CHK and this resulted in some build errors like
this:
```
/include/fortify/stdio.h: In function 'vsnprintf':
/include/fortify/stdio.h:155:49: error: "FORTIFY_USE_NATIVE_CHK" is not defined, evaluates to 0 [-Werror=undef]
155 | #if __has_builtin(__builtin___vsnprintf_chk) && FORTIFY_USE_NATIVE_CHK
| ^~~~~~~~~~~~~~~~~~~~~~
```
Check if it is defined instead.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
|
|
|
|
`strlen(src)` isn't guaranteed to be valid.
|
|
```
Core was generated by `scripts/mod/modpost -M -m -o Module.symvers -n -T modules.order vmlinux.o'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: 17 src/string/strlen.c: No such file or directory
(gdb) bt
```
> I think strncpy logic is broken: `__fh_size_t max_len_s = strlen(__s);` may try read past `size_t __n`.
> Create a buf without any trailing `\0`, do `strncpy(dest, buf, sizeof(buf));`, it should work, since `strncpy` will stop at `sizeof buf`
> but the current fority-headers implementation will do `strlen(buf)`, which will go boom when it is not terminated with \0
Reported-by: ncopa
|
|
As with previous commit, some strnlen calls
where introduced in 22a8094, but not reverted.
As strnlen isn't part of C standard,
this was breaking C builds.
|
|
As reported on irc:
```
17:51 <q> jvoisin, fortify-headers seems to be broken (on Alpine at least)
17:52 <q> Repeating the message from over-there:
17:52 <q> /usr/include/fortify/string.h: In function 'strncat':
17:52 <q> /usr/include/fortify/string.h:297:36: error: implicit declaration of function 'strnlen'; did you mean 'strlen'? [-Wimplicit-function-declaration]
17:52 <q> This is with a simple file that includes string.h and call strncat, built with c99 -O1 f.c
```
|
|
The dsize parameter is the length of the dst,
not the length of the src.
Reported-by: ncopa
|
|
just in case, and because 'PEDANTIC_CHECKS' is a really generic name
|
|
This was caught by the following test:
```
int main(void) {
char c[32];
memcpy(c, c + 16, 16);
}
```
Reported-by: q66
|
|
They can be re-enabled via `PEDANTIC_CHECKS`
|
|
Since C11:
> This function behaves as if it reads the bytes sequentially and stops as soon
as a matching bytes is found: if the array pointed to by ptr is smaller than
count, but the match is found within the array, the behavior is well-defined.
Reported-by: q66
|
|
See:
- https://www.imperialviolet.org/2016/06/26/nonnull.html
- https://davidben.net/2024/01/15/empty-slices.html
|
|
They were previously disabled in 80a83a5
|
|
|
|
They check overlap across the whole range of the given length, but
the given length is not what will actually be copied, rather it's
the maximum length (if src is shorter, only length of src will be
copied). This triggers false positives and traps where it shouldn't
(e.g. in ICU tests).
Reported-by: q66
|
|
|
|
It's UB to subtract null pointers, which these potentially may
be. It also makes python test suite fail.
|
|
|
|
This should fix #32
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It doesn't play nice with gcc.
|
|
|
|
|
|
|
|
It seems useless and triggers 'error: expected external declaration'
|
|
|
|
|
|
|
|
|
|
See https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html for
details
|
|
|
|
GCC and Clang provide __builtin_dynamic_object_size
(see documentation: https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html),
so we should make use of it when its available.
|
|
|
|
A few important notes:
* __extension__ is a GNU C "alternate" keyword, not a C++ keyword.[1]
* __extension__ is designed to work on "expressions"; it does work on
#include_next in C mode, but it has no effect in C++ mode; the
warning will still appear, if enabled, even with __extension__
preceding #include_next. This is because #include_next is not
considered an expression in C++, so the compiler attaches
__extension__ to the first expression of the header.
All of this leads us to a build failure while building at least all
Mozilla software. Moz has an alternate -isystem dir searched before
/usr/include that overrides some headers, including <features.h>. The
first statement in each of these headers is a #pragma, and since
__extension__ is looking for an expression, and #pragma is a "null"
expression, we end up with the following error:
dist/system_wrappers/features.h:1:9: error: '#pragma' is not allowed here
Since __extension__ has no effect on #include_next in C++ mode anyway,
and since it can cause breakage, this commit omits __extension__ in C++
mode.
[1]: https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Alternate-Keywords.html
|
|
|
|
Do not crash unless the overflow would happen.
|
|
Signed-off-by: Steven Barth <steven@midlink.org>
|
