| Age | Commit message (Collapse) | Author |
|---|
|
Previously, no checks were done when __n <= __b, but strncat _appends_ after
existing content, making this a overly broad check check. For example, with an
8-byte buffer containing "12345\0", strncat(buf, "ABCD", 4) would have the
check skipped, but the result "12345ABCD\0" is 10 bytes, resulting in an
overflow.
This commit fixes this oversight, and adds a bunch of tests.
|
|
mbsnrtowcs writes up to __wn wide characters into wchar_t *__d. The destination
capacity is __b / sizeof(wchar_t) wide characters, but the
else branch clamps __n (source byte limit) to __b (destination byte size).
__wn (the actual output count) is passed through unclamped. Example: __b=8
(dest holds 2 wchar_t), __n=100, __wn=25. The else branch applies (25 <=
100/4), clamps source to 8 bytes, but passes __wn=25 β the function can write
25 wchar_t (100 bytes) into an 8-byte buffer.
The first branch is also wrong: it divides __b (bytes) by sizeof(wchar_t) to
get wchar_t capacity, which is correct for the destination β but the condition
__wn > __n / sizeof(wchar_t) uses integer division that can produce incorrect
routing between branches.
The fix mirrors the already-correct mbsrtowcs pattern: clamp __wn (the output
wide-char count) to the destination's wchar_t capacity, and pass __n (source
byte limit) through unchanged.
|
|
|
|
Like it's already done for memcpy and memmove. Add tests as well,
to prove that nothing broke.
|
|
__d is a char * destination buffer, so __b is already the byte capacity.
Dividing by sizeof(wchar_t) makes no sense here, it was likely copy-pasted
from mbsnrtowcs (where the destination is wchar_t *). The first branch also
fails to limit __n (the byte write cap) to __b, so overflows are possible when
a wide character produces multi-byte output. The second branch (else) correctly
limits __n to __b.
This commit replaces the broken two-branch logic with the simple correct
pattern matching wcsrtombs, and adds two tests two prove that nothing broke.
|
|
The manpage says that stpncpy will "copy non-null bytes from the string pointed
to by src into the array pointed to by dst.", it doesn't add a terminal NULL
byte, so we shouldn't check for it.
|
|
This was fixed in a255506ca487250255f9f048e61cf90166ceab77
|
|
Fixes CXXFLAGS missing -I../include/ and avoids similar issues to happen
in the future
|
|
Exposes bug in c++ compile test which do not include fortify-headers
|
|
As explained in `man realpath(3)`:
> The POSIX.1-2001 standard version of this function is broken by design,
> since it is impossible to determine a suitable size for the output
> buffer, resolved_path. According to POSIX.1-2001 a buffer of size PATH_MAX
> suffices, but PATH_MAX need not be a defined constant, and may have to be
> obtained using pathconf(3). And asking pathconf(3) does not really help,
> since, on the one hand POSIX warns that the result of pathconf(3) may be huge
> and unsuitable for mallocing memory, and on the other hand pathconf(3) may
> return -1 to signify that PATH_MAX is not bounded. The reβ solved_path
> == NULL feature, not standardized in POSIX.1-2001, but standardized in
> POSIX.1-2008, allows this design problem to be avoided.
So we can either not compile, or be pragmatic, and define PATH_MAX to a sane
value, like 4096, which is the one used on Linux and some/most BSD.
This commit also adds two tests to ensure that things aren't catastrophically
broken by this change.
|
|
Notably -Wno-fortify-source, to prevent clang from using its own fortify
implementation.
Co-Authored-By: Sertonix
|
|
This commit fixes the typo pass_object_size__ for pass_object_size. It also
adds tests in the CI to prevent this from happening again.
Ref https://clang.llvm.org/docs/AttributeReference.html#pass-object-size-pass-dynamic-object-size
Co-Authored-By: Sertonix
|
|
Co-Authored-By: q66 <q66@chimera-linux.org>
|
