| Age | Commit message (Collapse) | Author |
|---|
|
`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
|
|
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
|
|
|
|
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.
|
|
|
|
|
|
|
|
Fixes https://github.com/jvoisin/fortify-headers/issues/34
|
|
Fixes https://github.com/jvoisin/fortify-headers/issues/31
|
|
|
|
This should fix #32
|
|
|
|
|
|
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110834
Reported-by: ksperling-apple
|
|
This is unlikely to be used, since fd_set is
usually manipulated by macros, but it doesn't hurt
to add a simple comparison.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
