| 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.
|
|
It's unfortunately valid to pass a buffer smaller than MB_CUR_MAX to wctomb, so
let's not trap on this. Moreover, it's supposed to be implemented in stdlib.h
and not wchar.h anyway.
|
|
Co-Authored-By: jvoisin <julien.voisin@dustri.org>
|
|
It seems useless and triggers 'error: expected external declaration'
|
|
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.
|
|
This allows the compiler to optimize out the slow/trap path at all
for the typical correct code:
char buf[MB_LEN_MAX];
r = wctomb(buf, c);
The change tries to keep the "unknown object size" case handling in
wcrtomb() as is even if it seems redundant and not helping (we copy
__buf to possibly undersized __s in any case) and inconsistent with
wctomb() (where we let the original library method itself overwrite
the possibly undersized __s).
|
|
|
|
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
|
|
The POSIX definition of wcrtomb
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/wcrtomb.html)
states:
"When wc is not a valid wide character, an encoding error shall occur.
In this case, the function shall store the value of the macro [EILSEQ]
in errno and shall return (size_t)-1; the conversion state shall be
undefined."
The fortify-headers implementation of wcrtomb interprets the result -1
as 18446744073709551615 bytes. Since this is the highest 64-bit number
possible, it is pretty safe to say this will always be larger than any
buffer provided to wcrtomb. Therefore, it traps.
Fixes bug https://bugs.alpinelinux.org/issues/7681.
Patch by A. Wilcox <AWilcox@Wilcox-Tech.com>
|
|
|
|
This was breaking valid code, example:
char c;
wcrtomb(&c, L'0', st);
|
|
Signed-off-by: Steven Barth <steven@midlink.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Overriding functions with macros is legal in C but a lot of software
is not prepared for it. Use the extern inline method to achieve the
same result.
|
|
fortify-headers is considered part of the implementation.
|
|
It is not legal to override standard functions using macros in C++.
We may have to revisit this in the future.
|
|
|
|
Some of these functions allow the destination pointer to be NULL.
Do not trap in that case as nothing will be written to the destination
buffer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
