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.
The principal expressions defining acosh and acos are such that
acosh(z) = ±i acos(z)
where the + is only true on the Im(z)>0 half of the complex plane
(and partly on Im(z)==0 depending on number representation).
fix the comment without expanding on the details.
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.
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.
__res_send returns the full answer length even if it didn't fit the
buffer, but __dns_parse expects the length of the filled part of the
buffer.
This is analogous to commit 77327ed064,
which fixed the only other __dns_parse call site.
A child process created by posix_spawn reports errors to its parent via
a pipe, retrying infinitely on any write error to prevent falsely
reporting success. If the (original) parent dies before write is
attempted, there is nobody to report to, but the child will remain
stuck in the write loop forever if SIGPIPE is blocked or ignored.
Fix this by not retrying write if it fails with EPIPE.
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.
commit 0dc4824479 worked around for lack
of flags argument in syscall for fchmodat.
linux 6.6 introduced a new syscall, SYS_fchmodat2, fixing this
deficiency. use it if any flags are passed, and fallback to the old
strategy on ENOSYS. continue using the old syscall when there are no
flags. this is the exact same strategy used when SYS_faccessat2 was used
to implement faccessat with flags.
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.
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.
Previously, __riscv_flush_icache would not work correctly as
__vdso_flush_icache had a wrong symbol version. Fix this by correcting
symbol version.
Fixes: 0a48860c27 ("add riscv64 architecture support")
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.
As entries in mtab are delimited by spaces, whitespace characters
are escaped as octal sequences. When reading them out, we have to
unescape these sequences to get the proper string.
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.
The name resolution would abort when getting more than 63 records per
request, due to what seems to be a left-over from the original code.
This check was non-breaking but spurious prior to TCP fallback
support, since any 512-byte packet with more than 63 records was
necessarily malformed. But now, it wrongly rejects valid results.
Reported by Daniel Stefanik in Alpine Linux aports issue 15320.
AT_NO_AUTOMOUNT is implied for stat/lstat/fstatat syscalls since Linux
3.1 (commit b6c8069d3577481390b3f24a8434ad72a3235594). However, this
is not the case for statx syscall, which defaults to automounting, so
this flag must be passed explicitly when statx is used to implement
stat-like functions.
This change affects only arches which use 32-bit seconds in struct kstat,
as well as out-of-tree/future ports to arches which lack SYS_fstatat.
C11 6.11.5p1:
> The placement of a storage-class specifier other than at the
> beginning of the declaration specifiers in a declaration is an
> obsolescent feature.
gcc also warns about this.
If __synccall() fails to capture all threads because tkill fails for
some reason other than EAGAIN, then the callback given will never be
executed, so nothing will ever overwrite the initial value. So that is
the value that will be returned from the function. The previous setting
of 1 is not a valid value for setuid() et al. to return.
I chose -EAGAIN since I don't know the reason the synccall failed ahead
of time, but EAGAIN is a specified error code for a possibly temporary
failure in setuid().
The code intends for the sem_post() in line 97 (now 98) to only unblock
target threads waiting on line 29. But after the first thread is
released, the next sem_post() might also unblock a thread waiting on
line 36. That would cause the thread to return to the execution of user
code before all threads are done, leading to user code being executed in
a mixed-credentials environment.
What's more, if this happens more than once, then the mass release on
line 110 (now line 111) will cause multiple threads to execute the
callback at the same time, and the callbacks are currently not written
to cope with that situation.
Adding another semaphore allows the caller to say explicitly which
threads it wants to release.
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.
This is the only missing part in struct statvfs. The LSB calls
[f]statfs() deprecated, and its weird types are definitely
off-putting. However, its use is required to get f_type.
Instead, allocate one of the six spares to f_type, copied directly
from struct statfs. This then becomes a small extension to the
standard interface on Linux, instead of two different interfaces, one
of which is quite odd due to being an ABI type, and there no longer is
any reason to use statfs().
The underlying kernel type is a mess, but all architectures agree on u32
(or more) for the ABI, and all filesystem magicks are 32-bit integers.
Since commit 6567db65f4 (prior to
1.0.0), the spare slots have been zero-filled, so on all versions that
may be reasonably be encountered in the wild, applications can rely on
a nonzero f_type as indication that the new field has been filled in.
powl used >= LDBL_MAX as infinity check, but LDBL_MAX is finite, so
this can cause wrong results e.g. powl(LDBL_MAX, 0.5) returned inf
or powl(2, LDBL_MAX) returned inf without raising overflow.
huge y values (close to LDBL_MAX) could cause intermediate results to
overflow (computing y * log2(x) with more than long double precision)
and e.g. powl(0.5, 0x1p16380L) or powl(10, 0x1p16380L) returned nan.
this is fixed by handling huge y early since that always overflows or
underflows.
reported by Paul Zimmermann against expl10 (which uses powl).
acosh(x) is nan for x < 1, but x < 0 cases were not handled specially
and acoshl gave wrong result for some -0x1p32 < x < -2 values, e.g.:
acoshl(-0x1p20) returned -inf,
acoshl(-0x1.4p20) returned -0x1.db365758403aa9acp+0L,
fixed by checking the sign bit and handling it specially.
reported by Paul Zimmermann.
the __dns_parse code used by the stub resolver traditionally included
code to reject label pointers to offsets past a 512 byte limit,
despite never processing the label contents, only stepping over them.
when commit 51d4669fb9 added support for
tcp fallback, this limit was overlooked, and as a result, it was at
least theoretically possible for some valid large answers to be
rejected on account of these offsets.
since the limit was never serving any useful purpose, just remove it.
