commit f96e47a261 introduced a new
overflow past the end of the base-1e9 buffer for floating point to
decimal conversion while fixing a different overflow below the start
of the buffer.
this bug has not been present in any release, and has not been
analyzed in depth for security considerations.
the root cause of the bug, incorrect size accounting for the mantissa,
long predates the above commit, but was only exposed once the
excessive offset causing overflow in the other direction was removed.
the number of slots for expanding the mantissa was computed as if each
slot could peel off at least 29 bits. this would be true if the
mantissa were placed and expanded to the left of the radix point, but
we don't do that because it would require repeated fmod and division.
instead, we start the mantissa with 29 bits to the left of the radix
point, so that they can be peeled off by conversion to integer and
subtraction, followed by a multiplication by 1e9 to prepare for the
next iteration. so while the first slot peels 29 bits, advancing to
the next slot adds back somewhere between 20 and 21 bits: the length
of the mantissa of 1e9. this means we need to account for a slot for
every 8 bits of mantissa past the initial 29.
add a comment to that effect and adjust the max_mant_slots formula.
per the psABI, floating point register contents beyond the register
size of the targeted ABI variant are never call-saved, so no
hwcap-conditional logic is needed here and the assembly-time
conditions are based purely on ABI variant macros, not the targeted
ISA level.
the ctr and xer special registers are call-clobbered and
syscall-clobbered. failure to include them in the clobber list may
result in wrong code that attempts to use a value which is no longer
present in the register after the syscall. this has been reported to
manifest newly with gcc 15.
v4-compatible addresses in ipv6 are a deprecated feature where the
high 96 bits are all zero and an ipv4 address is stored in the low
32 bits. however, since :: and ::1 are the unspecified and loopback
addresses, these two particular values are excluded from the
definition of the v4-compat class.
our version of the macro incorrectly assessed this condition by
checking only the high 96 and low 8 bits. this incorrectly excluded
the v4compat version of any ipv4 address ending in .1, not just ::1.
rather than writing out non-obvious or error-prone conditions on the
individual address bytes, just express the "not :: or ::1" condition
naturally using the existing IN6_IS_ADDR_UNSPECIFIED and
IN6_IS_ADDR_LOOPBACK macros, after checking that the high 96 bits are
all zero. any vaguely reasonable compiler will collapse out the
redundant tests of the upper bits as part of CSE.
as stated in the comment added, the ABI for SME requires libc to be
aware of and support the extension to the register file. this is
necessary to handle lazy saving correctly across setjmp/longjmp, and
on older kernels, in order not to introduce memory corruption bugs
that may be exploitable vulnerabilities when creating new threads.
previously, we did not expose __getauxval, the interface libgcc uses
to determine runtime availability of SME, so it was not usable when
following the intended ABI. since commit
ab4635fba6 has now exposed this
interface, a mitigation is needed to ensure SME is not used
unless/until we have proper support for it.
while SME is the current hwcap feature that needs this treatment,
as-yet-undefined hwcap bits are also masked in case other new cpu
features have similar ABI issues. this could be re-evaluated at some
point in the future.
for now, the masking is only on aarch64. arguably it should be
considered for all archs, but whether it's needed is really a matter
of how ABI policy & stability are handled by the maintainers of the
arch psABI, and aarch64 is the one that's demonstrated a necessity. if
it turns out something like this is needed for more/all archs, making
a generalized framework for it would make sense. for now, it's stuffed
into __set_thread_area the same way atomics detection is stuffed there
for 32-bit arm and sh, as it's a convenient point for "arch-specific
early setup code" without invasive changes.
this change both aligns with the intended future direction for most
assembly usage, and makes it possible to add arch-specific setup logic
based on hwcaps like we have for 32-bit arm.
commit 572a2e2eb9 adjusted the buffer
for decimal conversion to be a VLA that only uses the full size needed
for long double when the argument type was long double. however, it
failed to update a later expression for the positioning within the
buffer, which still used a fixed offset of LDBL_MANT_DIG. this caused
doubles with a large positive exponent to overflow below the start of
the array, producing wrong output and potentially runaway wrong
execution.
this bug has not been present in any release, and has not been
analyzed in depth for security considerations.
it turns out the original buffer offset expression involving
LDBL_MANT_DIG was incorrect as well, and only worked because the space
reserved for expanding the exponent is roughly 3 times the size it
needs to be when the exponent is positive, leaving plenty of extra
space to compensate for the error. the actual offset should be in
base-1000000000 slot units, not bits, and numerically equal to the
number of slots that were previously allocated for mantissa expansion.
in order to ensure consistency and make the code more comprehensible,
commented subexpressions are replaced by intermediate named variables,
and the newly introduced max_mant_slots is used for both the
allocation and the buffer offset adjustment. the included +1 term
accounts for a trailing zero slot that's always emitted.
This is needed so that libgcc can access AT_HWCAP without violating
link namespace rules.
Internally musl already used __getauxval symbol for the same reason,
we just remove the hidden marking.
Linux kernel commit ee988c11acf6f9464b7b44e9a091bf6afb3b3a49 added two
new HWCAP bits: one for ARCH_3_1, which is the Power10 ISA revision, and
one for MMA, which is the optional Matrix Multiply Assist extension.
When buffering on a FILE is disabled we still send both iovecs, even
though the first one is always empty. Clean things up by skipping the
empty iovec instead.
POSIX 2024 added a requirement that mbsnrtowcs, like mbrtowc, consume
any final partial character and store it in the mbstate_t object
before returning. this was previously unspecified but documented as a
potential future change.
an internal mbstate_t object is added for the case where the argument
is a null pointer. previously this was not needed since no operations
could modify the internal object and not processing it at all gave the
same behavior "as if" there were an internal object.
some recent compilers have adopted a dubious interpretation of the C
specification for union initializers, that when the initialized member
is smaller than the size of the union, the remaining padding does not
have to be zero-initialized. in the interests of not depending on any
particular interpretation, place the larger member first so it's
initialized and ensures the whole object is zero-filled.
traditionally, our cfsetispeed just set the output speed. this was not
conforming or reasonable behavior.
use of the input baud bits in termios c_cflag depends on kernel
support, which was added to linux along with TCSETS2 ioctl and
arbitrary-baud functionality sometime in the 2.6 series. with older
kernels, the separate input baud will not take, but this is the best
behavior we can hope for anyway, certainly better than wrongly
clobbering output baud setting.
the nonstandard cfsetspeed is now moved to a separate file, since it
no longer admits the weak alias implementation that made it
namespace-safe. it now sets the output speed, and on success, sets the
input speed to 0 (matched to output).
This just mirrors what is done in the start code for the affected
ports, as well as what is already done for the three x86 ports.
Clearing the frame pointer helps protect FP-based unwinders from
wrongly attempting to traverse into the parent thread's call frame
stack.
this function is documented as returning a null pointer on failure and
the current textdomain encoding, which is always UTF-8 in our
implementation, on success. there was some confusion over whether it's
expected to also return a null pointer in the case where it's using
the locale's encoding by default, rather than an explicitly bound one,
but it does not seem like that behavior would match applications'
expectations, and it would require gratuitously storing a meaningless
1-bit state for the textdomain.
the UTF-8 output code was written assuming an invariant that iconv's
decoders only emit valid Unicode Scalar Values which wctomb can encode
successfully, thereby always returning a value between 1 and 4.
if this invariant is not satisfied, wctomb returns (size_t)-1, and the
subsequent adjustments to the output buffer pointer and remaining
output byte count overflow, moving the output position backwards,
potentially past the beginning of the buffer, without storing any
bytes.
the man page for this nonstandardized function has historically
documented it as scanning for a substring; however, this is
functionally incorrect (matches the substring "atime" in the "noatime"
option, for example) and differs from other existing implementations.
with the change made here, it should match glibc and other
implementations, only matching whole options delimited by commas or
separated from a value by an equals sign.
as a result of incorrect bounds checking on the lead byte being
decoded, certain invalid inputs which should produce an encoding
error, such as "\xc8\x41", instead produced out-of-bounds loads from
the ksc table.
in a worst case, the loaded value may not be a valid unicode scalar
value, in which case, if the output encoding was UTF-8, wctomb would
return (size_t)-1, causing an overflow in the output pointer and
remaining buffer size which could clobber memory outside of the output
buffer.
bug report was submitted in private by Nick Wellnhofer on account of
potential security implications.
out-of-range second bytes were not handled, leading to wrong character
output rather than a reported encoding error.
fix based on bug report by Nick Wellnhofer, submitted in private in
case the issue turned out to have security implications.
Calling __tls_get_addr with brasl is not valid since it's a global symbol; doing
so results in an R_390_PC32DBL relocation error from lld. We could fix this by
marking __tls_get_addr hidden since it is not part of the s390x ABI, or by using
a different instruction. However, given its simplicity, it makes more sense to
just manually inline it into __tls_get_offset for performance.
The patch has been tested by applying to Zig's bundled musl copy and running the
full Zig test suite under qemu-s390x.
Some weird linkers may emit PT_LOAD segments with memsz = 0. ELF
specification does not forbid this, but such a segment with non-zero
p_vaddr will result in reclaiming of invalid memory address.
This patch skips such segments during reclaiming for better
compatibility.
we have the cpuset macros call calloc/free/memset/memcmp directly so
that they don't depend on any further ABI surface. this is not
namespace-clean, but only affects the _GNU_SOURCE feature profile,
which is not intended to be namespace-clean. nonetheless, reports come
up now and then of things which are gratuitously broken, usually when
an application has wrapped malloc with macros.
this patch parenthesizes the function names so that function-like
macros will not be expanded, and removes the unused declaration of
memcpy. this is not a complete solution, but it should improve things
for affected applications, particularly ones which are not even trying
to use the cpuset interfaces which got them just because g++ always
defines _GNU_SOURCE.
the kernel mq_attr structure has 8 64-bit longs instead of 8 32-bit
longs.
it's not clear that this is the nicest way to implement the fix, but
the concept (translation) is right, and the details can be changed
later if desired.
previously, we left any changes made by the application to the timer
thread's signal mask active when resetting the thread state for reuse.
not only did this violate the intended invariant that timer threads
start with all signals blocked; it also allowed application code to
execute in a thread that, formally, did not exist. and further, if the
internal SIGTIMER signal became unblocked, it could also lead to
missed timer expiration events.
commit 6ae2568bc2 introduced a fatal
signal condition if the internal timer signal used for SIGEV_THREAD
timers is unblocked. this can happen whenever the application alters
the signal mask with SIG_SETMASK, since sigset_t objects never include
the bits used for implementation-internal signals.
this patch effectively reverts the breakage by adding back a no-op
signal handler.
overruns will not be accounted if the timer signal becomes unblocked,
but POSIX does not specify them except for SIGEV_SIGNAL timers anyway.
The LLVM assembler reportedly assembles the form using the j mnemonic
incorrectly (see issue 107460). The jr form is canonical and avoids
this problem, so use it instead.
When the pattern was changed from matching any whitespace to just
matching spaces and tabs, a newline started being appended to the
value of the matched field, if that field was a string. For example,
in a 4-field line, the mnt_opts field would have a newline on the end.
This happened because a newline is not a space or a tab, and so was
matched as part of the value before the end of the string was reached.
\n should therefore be added as a character that terminates a value.
This shouldn't interfere with the intention of the change to space and
tab only, as it was trying to make sure that other whitespace like
carriage returns, that should have been part of parsed values, were.
Fixes: f314e133
The instruction encoding that would be "br %r0" is not actually a
branch to r0, but instead a nop/memory-barrier. gcc 14 has been found
to choose r0 for the "r"(pc) constraint, breaking CRTJMP.
This patch adjusts the inline assembly constraints and marks "pc" as
address ("a"), which disallows usage of r0.
commit 8cca79a72c added use of SYS_pause
to exit() without accounting for newer archs omitting the syscall.
use the newly-added __sys_pause abstraction instead, which uses
SYS_ppoll when SYS_pause is missing.
newer archs lack the syscall. the pause() function accounted for this
with its own #ifdef, but that didn't allow use of the syscall directly
elsewhere, so move the logic to macros in src/internal/syscall.h where
it can be shared.
commit b817541f1c introduced statx with
a fallback using fstatat, but failed to fill in stx_rdev_major/minor
and stx_attributes[_mask]. the rdev omission has been addressed
separately. rather than explicitly zeroing the attributes and their
mask, pre-fill the entire structure with zeros. this will also cover
the padding adjacent to stx_mode, in case it's ever used in the
future.
explicit zeroing of stx_btime is removed since, with this change, it
will already be pre-zeroed. as an aside, zeroing it was not strictly
necessary, since STATX_BASIC_STATS does not include STATX_BTIME and
thus does not indicate any validity for it.
The current implementation of the statx function fails to set the
values of stx->stx_rdev_major and stx->stx_rdev_minor if the statx
syscall fails with ENOSYS and thus the statx function has to fall back
on fstatat-based emulation.
