this corrects missing validation when using alternate group database
backends via nscd, as reported by 0rbitingZer0, which could result in
a heap-based buffer overflow.
while the source of truth for user (passwd) and group definitions is
generally an equal or higher-privilege domain than the application,
and compromise of nscd could inherently lead to bypass of some access
controls, it is still worthwhile to harden against direct attacks from
a compromised nscd.
this patch adds validation in the least invasive way possible,
erroring out at the point where a write past the end of the buffer
would previously have occurred.
a check is also added for member counts that would cause arithmetic
overflow in the existing buffer size computations, including negative
counts. this could be handled better by making adjustments where the
arithmetic is performed, but the way it's done here avoids making any
changes except for the actual bounds check.
this flag works like MADV_DONTNEED but also applies to locked memory
ranges.
see
linux commit 9457056ac426e5ed0671356509c8dcce69f8dee0
mm: madvise: MADV_DONTNEED_LOCKED
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.
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.
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 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.
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.
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 value placed in the aux vector AT_MINSIGSTKSZ by the kernel is
purely the signal frame size, and does not include any execution space
for the signal handler. this is contrary to the POSIX definition of
MINSIGSTKSZ to be a value that can actually execute at least some
minimal signal handler, and contrary to the historical definitions of
MINSIGSTKSZ which had at least 1k of headroom.
commit 996b6154b2 added support for
querying the dynamic limit but did not enforce it in sigaltstack. the
kernel also does not seem to reliably enforce it, or at least does not
necessarily enforce the same limit exposed to userspace, so it needs
to be enforced here.
internally, printf always works with the maximal-size supported
integer and floating point formats. however, the space needed to
format a floating point number is proportional to the mantissa and
exponent ranges. on archs where long double is larger than double,
knowing that the actual value fit in double allows us to use a much
smaller buffer, roughly 1/16 the size.
as a bonus, making the working buffer a VLA whose dimension depends on
the format specifier prevents the compiler from lifting the stack
adjustment to the top of printf_core. this makes it so printf calls
without floating point arguments do not waste even the smaller amount
of stack space needed for double, making it much more practical to use
printf in tightly stack-constrained environments.
linux puts hung-up ttys in a state where ioctls produce EIO, and may
do the same for other types of devices in error or shutdown states.
such an error clearly does not mean the device is not a tty, but it
also can't reliably establish that the device is a tty, so the only
safe thing to do seems to be reporting the error. programs that don't
check errno will conclude that the device is not a tty, which is no
different from what happens now, but at least they gain the option to
differentiate between the cases.
commit c84971995b introduced the errno
collapsing behavior, but prior to that, errno was not set at all by
isatty.
this is purely a readability change, not a functional one. all of the
integer format cases use a common tail for handling precision logic
after the string representation of the number has been generated. the
code as I originally wrote it was overly clever in the aim of making a
point that the flow could be done without goto, and jumped over
intervening cases by wrapping them in if (0) { }, with the case labels
for each inside the conditional block scope.
this has been a perpetual source of complaints about the readability
and comprehensibility of the file, so I am now changing it to
explicitly jump to the tail logic with goto statements.
this is the same as cp850, but with the euro symbol replacing the
lowercase dotless i at 0xd5. it is significant because it's used by
thermal receipt printers.
the comment does not match the required or actual behavior when x<0
and y is not an integer. while it could be corrected, the role of
comments here is to tell about characteristics unique to the
implementation, not to restate the requirements of the standard, so
just removing it seems best.
while not the only error codes presently omitted, these two are
particularly likely to be encountered in the wild.
EUCLEAN is used by linux filesystem and device drivers to report
filesystem structure corruption or data corruption.
ENAVAIL is used by some linux drivers to indicate non-availability of
a resource.
both names are new inventions to correspond to how they are actually
used, as the original kernel strings ("Structure needs cleaning" and
"No XENIX semaphores available") are not remotely meaningful or
reasonable.
the file-level crt_arch.h asm fragments generally make direct
(non-PLT) calls from _start to _start_c, which is only valid when
there is a local, non-interposable definition for _start_c. generally,
the linker is expected to know that local definitions in a main
executable (as opposed to shared library) output are non-interposable,
making this work, but historically there have been linker bugs in this
area, and microblaze is reportedly still broken, flagging the
relocation for the call as a textrel.
the equivalent _dlstart_c, called from the same crt_arch.h asm
fragments, has always used hidden visibility without problem, and
semantically it should be hidden, so make it hidden. this ensures the
direct call is always valid regardless of whether the linker properly
special-cases main executable output.
if sem_post is interrupted between clearing the waiters bit from the
semaphore value and performing the futex wait operation, subsequent
calls to sem_post will not perform a wake operation unless a new
waiter has arrived.
usually, this is at most a minor nuisance, since the original wake
operation will eventually happen. however, it's possible that the wake
is delayed indefinitely if interrupted by a signal handler, or that
the address the wake needs to be performed on is no longer mapped if
the semaphore was a process-shared one that has since been unmapped
but has a waiter on a different mapping of the same semaphore. this
can happen when another thread using the same mapping "steals the
post" atomically before actually becoming a second waiter, deduces
from success that it was the last user of the semaphore mapping, then
re-posts and unmaps the semaphore mapping. this scenario was described
in a report by Markus Wichmann.
instead of checking only the waiters bit, also check the waiter count
that was sampled before the atomic post operation, and perform the
wake if it's nonzero. this will not produce any additional wakes under
non-race conditions, since the waiters bit only becomes zero when
targeting a single waiter for wake. checking both was already the
behavior prior to commit 159d1f6c02.
our pthread barrier implementation reportedly has bugs that are could
lead to malfunction or crash in timer_create. while this has not been
reviewed to confirm, there have been past reports of pthread barrier
bugs, and it seems likely that something is actually wrong.
pthread barriers are an obscure primitive, and timer_create is the
only place we are using them internally at present. even if they were
working correctly, this means we are imposing linking of otherwise
likely-dead code whenever timer_create is used.
a pair of semaphores functions identically to a 2-waiter barrier
except for destruction order properties. since the parent is
responsible for the argument structure (including semaphores)
lifetimes, the last operation on them in the timer thread must be
posting to the parent.
previously, global dtors, which are executed after all atexit handlers
have been called rather than being implemented as an atexit handler
themselves, would deadlock if they called atexit.
it was intentional to disallow adding more atexit handlers past the
last point where they would be executed, since a successful return
from atexit imposes a contract that the handler will be executed, but
this was only considered in the context of calls to atexit from other
threads, not calls from the dtors.
to fix this, release the lock after the exit handlers loop completes,
but but set a flag first so that we can make all future calls to
atexit return a failure code.
per the C and POSIX standards, calling exit "more than once",
including via return from main, produces undefined behavior. this
language predates threads, and at the time it was written, could only
have applied to recursive calls to exit via atexit handlers. C++
likewise makes calls to exit from global dtors undefined. nonetheless,
by the present specification as written, concurrent calls to exit by
multiple threads also have undefined behavior.
originally, our implementation of exit did have locking to handle
concurrent calls safely, but that was changed in commit
2e55da9118 based on it being undefined.
from a standpoint of both hardening and quality of implementation,
that change seems to have been a mistake.
this change adds back locking, but with awareness of the lock owner so
that recursive calls to exit can be trapped rather than deadlocking.
this also opens up the possibility of allowing recursive calls to
succeed, if future consensus ends up being in favor of that.
prior to this change, exit already behaved partly as if protected by a
lock as long as atexit was linked, but multiple threads calling exit
could concurrently "pop off" atexit handlers and execute them in
parallel with one another rather than serialized in the reverse order
of registration. this was a likely unnoticed but potentially very
dangerous manifestation of the undefined behavior. if on the other
hand atexit was not linked, multiple threads calling exit concurrently
could each run their own instance of global dtors, if any, likely
producing double-free situations.
now, if multiple threads call exit concurrently, all but the first
will permanently block (in SYS_pause) until the process terminates,
and all atexit handlers, global dtors, and stdio flushing/position
consistency will be handled in the thread that arrived first. this is
really the only reasonable way to define concurrent calls to exit. it
is not recommended usage, but may become so in the future if there is
consensus/standardization, as there is a push from the rust language
community (and potentially other languages interoperating with the C
runtime) to make concurrent calls to the language's exit interfaces
safe even when multiple languages are involved in a program, and this
is only possible by having the locking in the underlying C exit.
commit 895736d49b made these changes
along with fixing a real bug in LOG_MAKEPRI. based on further
information, they do not seem to be well-motivated or in line with
policy.
the result of LOG_FAC is not a meaningful facility value if we shift
it down like before, but apparently the way it is used by applications
is as an index into an array of facility names. moreover, all
historical systems which define it do so with the shift. as it is a
nonstandard interface, there is no justification for providing a macro
by the same name that is incompatible with historical practice.
the value of LOG_FACMASK likewise is 0x3f8 on all historical systems
checked. while only 5 bits are used for existing facility codes, the
convention seems to be that all 7 bits belong to the facility field
and theoretically could be used to expand to having more facilities.
that seems unlikely to happen, but there is no reason to make a
gratuitously incompatible change here.
while commit 53ac44ff4c fixed the temp
buffer being undersized, the use of a temp buffer to begin with was a
mistake. instead, compare the requested symbol name in-place and use
the already-null-terminated copy of the name without "64" present in
lfs64_list[] to look up the real symbol.
this interface does not have a lot of historical consensus on how it
handles the contents of the /etc/shells file in regard to whitespace
and comments, but the commonality between all checked is that they
ignore lines that are blank or that begin with '#', so that is the
behavior we adopt.
these are nonstandard and unnecessary for using the associated
functionality, but resulted in applications that used them
malfunctioning.
patch based on proposed fix by erny hombre.
commit 1b0d48517f wrongly copied the
getdents return type of int rather than matching the ssize_t used by
posix_getdents. this was overlooked in testing on 32-bit archs but
obviously broke 64-bit archs.
this interface was added as the outcome of Austin Group tracker issue
697. no error is specified for unsupported flags, which is probably an
oversight. for now, EOPNOTSUPP is used so as not to overload EINVAL.
the bits file is retained, but as a single generic version, to allow
for the unlikely future possibility of letting a new arch define
something differently.
previously, only a few archs defined it here. this change makes the
presence consistent across all archs, and reduces the amount of header
duplication (and potential for future inconsistency) between archs.
this change is purely to document that they are the same in
preparation to remove the arch-specific headers for these archs and
replace them with a generic version that matches riscv32 and can be
shared by these and all future archs.
commit f47a8cdd25 introduced an
alternate mechanism for access to runtime page size for compatibility
with early stages of dynamic linking, but because pthread_impl.h
indirectly includes libc.h, the condition #ifndef PAGE_SIZE was never
satisfied.
rather than depend on order of inclusion, use the (baseline POSIX)
macro PAGESIZE, not the (XSI) macro PAGE_SIZE, to determine whether
page size is dynamic. our internal libc.h only provides a dynamic
definition for PAGE_SIZE, not for PAGESIZE.
the %s conversion is added as the outcome of Austin Group tracker
issue 169 and its unspecified behavior is clarified as the outcome of
issue 1727.
the %F, %g, %G, %u, %V, %z, and %Z conversions are added as the
outcome of Austin Group tracker issue 879 for alignment with strftime
and the behaviors of %u, %z, and %Z are defined as the outcome of
issue 1727.
at this time, the conversions with unspecified effects on struct tm
are all left as parse-only no-ops. this may be changed at a later
time, particularly for %s, if there is reasonable cross-implementation
consensus outside the standards process on what the behavior should
be.
once the remaining value is less than 10, the modulo operation to
produce the final digit and division to prepare for next loop
iteration can be dropped. this may be a meaningful performance
distinction when formatting low-magnitude numbers in bulk, and should
never hurt.
based on patch by Viktor Reznov.
historically linux limited the number of supplementary groups a
process could be in to 32, but this limit was raised to 65536 in linux
2.6.4. proposals to support the new limit, change NGROUPS_MAX, or make
it dynamic have been stalled due to the impact it would have on
initgroups where the groups array exists in automatic storage.
the changes here decouple initgroups from the value of NGROUPS_MAX and
allow it to fall back to allocating a buffer in the case where
getgrouplist indicates the user has more supplementary groups than
could be reported in the buffer. getgrouplist already involves
allocation, so this does not pull in any new link dependency.
likewise, getgrouplist is already using the public malloc (vs internal
libc one), so initgroups does the same. if this turns out not to be
the best choice, both can be changed together later.
the initial buffer size is left at 32, but now as the literal value,
so that any potential future change to NGROUPS_MAX will not affect
initgroups.
commit cfa0a54c08 attempted to fix
rounding on archs where long double is not 80-bit (where LDBL_MANT_DIG
is not zero mod four), but failed to address the edge case where
rounding was skipped because LDBL_MANT_DIG/4 rounded down in the
comparison against the requested precision.
the rounding logic based on hex digit count is difficult to understand
and not well-motivated, so rather than try to fix it, replace it with
an explicit calculation in terms of number of bits to be kept, without
any truncating division operations. based on patch by Peter Ammon, but
with scalbn to apply the rounding exponent since the value will not
generally fit in any integer type. scalbn is used instead of scalbnl
to avoid pulling in the latter unnecessarily, since the value is an
exact power of two whose exponent range is bounded by LDBL_MANT_DIG, a
small integer.
POSIX requires pwrite to honor the explicit file offset where the
write should take place even if the file was opened as O_APPEND.
however, linux historically defined the pwrite syscall family as
honoring O_APPEND. this cannot be changed on the kernel side due to
stability policy, but the addition of the pwritev2 syscall with a
flags argument opened the door to fixing it, and linux commit
73fa7547c70b32cc69685f79be31135797734eb6 adds the RWF_NOAPPEND flag
that lets us request a write honoring the file offset argument.
this patch changes the pwrite function to first attempt using the
pwritev2 syscall with RWF_NOAPPEND, falling back to using the old
pwrite syscall only after checking that O_APPEND is not set for the
open file. if O_APPEND is set, the operation fails with EOPNOTSUPP,
reflecting that the kernel does not support the correct behavior. this
is an extended error case needed to avoid the wrong behavior that
happened before (writing the data at the wrong location), and is
aligned with the spirit of the POSIX requirement that "An attempt to
perform a pwrite() on a file that is incapable of seeking shall result
in an error."
since the pwritev2 syscall interprets the offset of -1 as a request to
write at the current file offset, it is mapped to a different negative
value that will produce the expected error.
pwritev, though not governed by POSIX at this time, is adjusted to
match pwrite in honoring the offset.
added in linux kernel commit 73fa7547c70b32cc69685f79be31135797734eb6.
this is added now as a prerequisite for fixing pwrite/pwritev behavior
for O_APPEND files.
the jis0208 table we use is only 84x94 in size, but the shift_jis
encoding supports a 94x94 grid. attempts to convert sequences outside
of the supported zone resulted in out-of-bounds table reads,
misinterpreting adjacent rodata as part of the character table and
thereby converting these sequences to unexpected characters.
this is not needed, but may act as a hint to the compiler, and also
serves to suppress unused function warnings if enabled (on by default
since commit 86ac0f7947).
this is how it's defined in the cp936 document referenced by the IANA
charset registry as defining GBK, and of the mappings defined there,
was the only one missing.
it is not accepted for GB18030, as GB18030 is a UTF and has its own
unique mapping for the euro symbol.
despite riscv32 being natively time64, the IPC_TIME64 bit (0x100) is
set in IPC_STAT and derived command macros, differentiating their
values from the raw command values used to interface with the kernel.
this reflects that the kernel ipc structure types are not natively
time64, but have broken-down hi/lo fields that cannot be used in-place
and require translation, and that the userspace struct types differ
from the kernel types (relevant to things like strace).
originally, compilers did not provide these macros and we had to
provide them ourselves. this meant we were redefining them, which was
technically invalid unless the token sequence of the original
definition matched exactly.
the original patch proposed by Jules Maselbas to fix this made the
definitions conditional on them not already being defined; however I
suggested using #undef to avoid any possibly-wrong definitions already
in place and ensure that the definitions are 1. the version adopted as
commit 8b70486807 made this change.
unfortunately, gcc is loud about not liking #undef of any __STDC_*
macro name, and while warnings are suppressed in the system include
path, there is apparently no way to suppress this warning if the
system include dir has also been provided via -I.
while normally we don't go out of our way to satisfy warnings over
style in the public headers, in this case, it seems to be a matter of
disagreement over contract of which part of "the implementation" is
entitled to define or undefine macros belonging to the implementation,
and it's quite reasonable to conclude that the compiler may reject
attempts to undefine them.
this commit reverts to the originally-submitted version of the patch
making the definitions conditional.
this code dates back to the original commit of the sh port, with no
real clue as to how the bug was introduced. it looks like it was
written to assume the return address was pushed to the stack like on
x86, rather than arriving in the pr special register.
see
linux commit 884a7e5964e06ed93c7771c0d7cf19c09a8946f1
mm: introduce process_mrelease system call
linux commit dce49103962840dd61423d7627748d6c558d58c5
mm: wire up syscall process_mrelease
this commit should make no codegen change for existing archs, but is a
prerequisite for new archs including riscv32. the wait4 emulation
backend provides both cancellable and non-cancellable variants because
waitpid is required to be a cancellation point, but all of our other
uses are not, and most of them cannot be.
based on patch by Stefan O'Rear.
commit f47a5d400b overlooked that
strtoul was responsible for setting p to a const-laundered copy of the
format string pointer f, even in the case where there was no number to
parse. by making the call conditional on isdigit, that copy was lost.
the logic here is a mess and should be cleaned up, but for now, this
seems to be the least invasive change that undoes the breakage.
commit f247462b08 incorrectly hid ppoll
in the presence of _GNU_SOURCE due to an oversight that defining
_BSD_SOURCE does not implicitly define _GNU_SOURCE. at present,
headers still have to explicitly check for each feature profile level;
this may be changed at some point in the future via features.h, but
has not been changed yet.
depending on contents of the LC_TIME locale, log messages could be
malformatted (especially if the ABMON strings contain non-alphabetic
characters) or the subsequent code could invoke undefined behavior,
via passing a timebuf[] with unspecified contents to snprintf, if
the translated ABMON string did not fit in the 16-byte timebuf.
this does not appear to be a security-relevant bug, as locale loading
functionality is intentionally not available to set*id programs -- the
MUSL_LOCPATH environment variable is ignored when libc.secure is true,
and custom locales are not loadable without it.
having these constants be static was unnecessary, so just remove the
static.
this error should have been caught by compilers, but recent versions
of both gcc and clang accept these as "other forms of constant
expressions" which the C standard allows.
the ppoll function has been accepted as a future part of the standard
as the outcome of Austin Group tracker issue 1263. at some point it
should be exposed unconditionally, but for now, expose it in the
default feature profile.
the ppoll function has been accepted as a future part of the standard
as the outcome of Austin Group tracker issue 1263. move the source
file to reflect this.
this was a POSIX requirement that was always in conflict with ISO C,
which specified a well-defined behavior for snprintf and swprintf so
long as the actual number of bytes/characters produced did not exceed
INT_MAX.
I originally raised this conflict for snprintf with the Austin Group
as tracker issue 761, which was never resolved. it was later reported
again as issue 1219, and as a result the conflicting requirement has
been removed.
the corresponding issue with swprintf does not seem to have been
addressed, but as the same reasoning applies to it, I am removing the
limitation on n for swprintf as well.
strtoul will consume leading whitespace or sign characters, which are
not valid in this context, thereby accepting invalid field specifiers.
so, avoid calling it unless there is a number to parse as the width.
this matters because the kernel-provided mtab only escapes tabs,
spaces, newlines, and backslashes. it leaves carriage returns, form
feeds, and vertical tabs literal.
presently this only affects 32-bit arm. despite correctly reversing
the function pointer and argument fields based on the
TLSDESC_BACKWARDS macro, we did not read the addend from the
swapped-order argument field, so nonzero addends were lost, producing
wrong runtime addresses for TLS objects needing an addend.
based on report and patch by Rui Ueyama.
this is contrary to the spec as written, which requires %lc to behave
as if it were %ls on a 2-wchar_t buffer containing the argument and
zero. however, apparently no other implementations conform to the spec
as written, and in response to Austin Group issue #1647, WG14 chose to
align with existing practice and have %lc produce output for this case.
previously, the relative load address was used as the address at which
to find the ELF headers. this only works if two conditions are met:
ldso is linked to start at a virtual address of 0, and the linker is
cooperative and includes the main ELF headers in a loadable segment.
while in practice these are always met, modern linkers provide a
__ehdr_start symbol pointing to the ELF headers, and can in principle
use the reference to this symbol as an indication that they need to be
mapped in a segment. this also should make it possible to link for a
different starting virtual address, if that's ever desirable.
commit 37bb3cce45 suppressed the
declaration for C++, where it is wrongly interpreted as declaring the
function as taking no arguments. with C23 removing non-prototype
declarations, that problem is now also relevant to C.
the non-prototype declaration for basename originates with commit
06aec8d715, where it was designed to
avoid conflicts with programs which declare basename with the GNU
signature taking const char *. that change was probably misguided, as
it represents not only misaligned expectations with the caller, but
also undefined behavior (calling a function that's been declared with
the wrong type).
we could opt to fix the declaration, but since glibc, with the
gratuitously incompatible GNU-basename function, seems to be the only
implementation that declares it in string.h, it seems better to just
remove the declaration. this provides some warning if applications are
being built expecting the GNU behavior but not getting it. if we
declared it here, it would only produce a warning if the caller also
declares it themselves (rare) or if the caller attempts to pass a
const-qualified pointer.
when the result count was zero, glob was ignoring a possible
GLOB_ABORTED error code and returning GLOB_NOMATCH. whether this
happened could be nondeterministic and dependent on the order of
dirent enumeration, in cases where multiple matches were present and
only some produced errors.
caught by Tor's test_util_glob.
Rich Felker