| 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
|
|
|
|
|
|
Apparently, clang doesn't like the `putwchar` function for no good reason.
Replacing it with `printf` fixes a NULL-ptr deref, so let's do that, as we
don't really care about the content of the buffer anyway, only that it's not
optimized away.
|
|
|
|
|
|
GCC complains about the `defined` usage here. Just call `__has_builtin` directly.
This fixes the following compile error when compiling strace:
```
In file included from /home/hauke/openwrt/openwrt/staging_dir/toolchain-aarch64_generic_gcc-14.3.0_musl/include/fortify/stdlib.h:27,
from number_set.c:14:
/home/hauke/openwrt/openwrt/staging_dir/toolchain-aarch64_generic_gcc-14.3.0_musl/include/fortify/fortify-headers.h:26:30: error: this use of "defined" may not be portable [-Werror=expansion-to-defined]
26 | #define __fh_has_builtin(x) (__has_builtin(x) || defined(x))
| ^~~~~~~~~~~~~
/home/hauke/openwrt/openwrt/staging_dir/toolchain-aarch64_generic_gcc-14.3.0_musl/include/fortify/fortify-headers.h:28:7: note: in expansion of macro '__fh_has_builtin'
28 | #if ! __fh_has_builtin(__builtin_trap)
| ^~~~~~~~~~~~~~~~
/home/hauke/openwrt/openwrt/staging_dir/toolchain-aarch64_generic_gcc-14.3.0_musl/include/fortify/fortify-headers.h:26:30: error: this use of "defined" may not be portable [-Werror=expansion-to-defined]
26 | #define __fh_has_builtin(x) (__has_builtin(x) || defined(x))
| ^~~~~~~~~~~~~
/home/hauke/openwrt/openwrt/staging_dir/toolchain-aarch64_generic_gcc-14.3.0_musl/include/fortify/fortify-headers.h:73:29: note: in expansion of macro '__fh_has_builtin'
73 | #if _FORTIFY_SOURCE > 2 && __fh_has_builtin (__builtin_dynamic_object_size)
| ^~~~~~~~~~~~~~~~
/home/hauke/openwrt/openwrt/staging_dir/toolchain-aarch64_generic_gcc-14.3.0_musl/include/fortify/fortify-headers.h:26:30: error: this use of "defined" may not be portable [-Werror=expansion-to-defined]
26 | #define __fh_has_builtin(x) (__has_builtin(x) || defined(x))
| ^~~~~~~~~~~~~
/home/hauke/openwrt/openwrt/staging_dir/toolchain-aarch64_generic_gcc-14.3.0_musl/include/fortify/fortify-headers.h:158:5: note: in expansion of macro '__fh_has_builtin'
158 | #if __fh_has_builtin (__builtin_mul_overflow_p)
| ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
|
|
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>
|
|
Treat _REDIR_TIME64 being undefined like being set to 0.
This fixes the following compile error in strace:
```
In file included from pathtrace.c:12:
/include/fortify/poll.h:46:30: error: "_REDIR_TIME64" is not defined, evaluates to 0 [-Werror=undef]
46 | #if defined(_GNU_SOURCE) && !_REDIR_TIME64
| ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
|
|
We know clang isn't working great for now, and we still need the CI to fix
bugs.
|
|
|
|
f09abdf6e236198e6dbf7d049dc99534d9f8af01
|
|
|
|
Make the overlap check pedantic only since some software seems to rely
on glibc working when src and dest are the same.
|
|
|
|
|
|
|
|
See https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82065
|
|
Add some ifdef guards around `getlogin_r`.
|
|
|
|
`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.
|
|
This fixes invalid conversion errors when the fd_set is defined as
const.
fixes https://github.com/jvoisin/fortify-headers/issues/66
|
|
Avoid installing *.orig or other files.
|
|
It seems that annotating sprintf with `write` makes gcc unhappy, as its
analyser is unable to understand that we're checking if `__b != -1` before
calling `__orig_snprintf`, so let's comment this annotation for now.
|
|
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
|
|
In the same spirit as the previous commit.
Reported-by: ncopa
|
|
This fix the following issue:
```
In file included from exec-cmd.c:9:
In function 'vsnprintf',
inlined from 'report.constprop' at subcmd-util.h:13:2:
/usr/include/fortify/stdio.h:162:16: error: 'msg' may be used uninitialized [-Werror=maybe-uninitialized]
162 | return __orig_vsnprintf(__s, __n, __f, __v);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/fortify/strings.h:23,
from /usr/include/string.h:59,
from /usr/include/fortify/string.h:23,
from /home/ncopa/aports/main/linux-lts/src/linux-6.6/tools/include/linux/string.h:6,
from exec-cmd.c:3:
/usr/include/fortify/stdio.h: In function 'report.constprop':
/usr/include/fortify/stdio.h:152:1: note: in a call to '__orig_vsnprintf' declared with attribute 'access (read_write, 1, 2)' here
152 | _FORTIFY_FN(vsnprintf) int vsnprintf(char * _FORTIFY_POS0 __s, size_t __n,
| ^~~~~~~~~~~
In file included from exec-cmd.c:10:
subcmd-util.h:12:14: note: 'msg' declared here
12 | char msg[1024];
| ^~~
cc1: all warnings being treated as errors
make[5]: *** [/home/ncopa/aports/main/linux-lts/src/linux-6.6/tools/build/Makefile.build:98: /home/ncopa/aports/main/linux-lts/src/build-virt.x86_64/tools/objtool/libsubcmd/exec-cmd.o] Error 1
make[4]: *** [Makefile:80: /home/ncopa/aports/main/linux-lts/src/build-virt.x86_64/tools/objtool/libsubcmd/libsubcmd-in.o] Error 2
make[3]: *** [Makefile:78: /home/ncopa/aports/main/linux-lts/src/build-virt.x86_64/tools/objtool/libsubcmd/libsubcmd.a] Error 2
make[2]: *** [Makefile:73: objtool] Error 2
make[1]: *** [/home/ncopa/aports/main/linux-lts/src/linux-6.6/Makefile:1362: tools/objtool] Error 2
make: *** [/home/ncopa/aports/main/linux-lts/src/linux-6.6/Makefile:234: __sub-make] Error 2
```
Reported-by: ncopa
|
|
just in case, and because 'PEDANTIC_CHECKS' is a really generic name
|
|
|
|
|
|
This should fix the second part of #59
|
|
- They're not used anywhere else in fortify-headers
- It's breaking compilation on C++, because compatibility is hard
It was initially reported on https://gitlab.alpinelinux.org/alpine/aports/-/issues/16200
|
|
The only hardening being done here is to set the char** parameter to thos
functions to NULL in case of an error, to prevent it from being used should
people forget to check return values. This is already done on some BSD, as well
as in Rocky Linux.
|
|
|
|
|
|
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
|
|
|
|
Clang's [documentation](https://clang.llvm.org/docs/LanguageExtensions.html#has-builtin) says:
> __has_builtin should not be used to detect support for a builtin macro; use #ifdef instead.
So we're now using both, since it's often tedious/non-trivial to find out
what is a macro and what is a compiler builtin, across compilers and C
versions.
|
|
They were previously disabled in 80a83a5
|
|
|
|
|
|
|
