user_regs_struct and user_fp_struct were missing from the initial
commit of the port.
the union type for elf_fpreg_t and the new value of ELF_NFPREG are
made consistent with glibc.
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.
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.
the linux fchmodat syscall lacks a flag argument that is necessary to
implement the posix api, see
linux commit 09da082b07bbae1c11d9560c8502800039aebcea
fs: Add fchmodat2()
linux commit 78252deb023cf0879256fcfbafe37022c390762b
arch: Register fchmodat2, usually as syscall 452
see
linux commit cf264e1329fb0307e044f7675849f9f38b44c11a
cachestat: implement cachestat syscall
linux commit 946e697c69ffeeefdd84dad90eac307284df46be
cachestat: wire up cachestat for other architectures
see
linux commit c6018b4b254971863bd0ad36bb5e7d0fa0f0ddb0
mm/mempolicy: add set_mempolicy_home_node syscall
linux commit 21b084fdf2a49ca1634e8e360e9ab6f9ff0dee11
mm/mempolicy: wire up syscall set_mempolicy_home_node
see
linux commit 039c0ec9bb77446d7ada7f55f90af9299b28ca49
futex,x86: Wire up sys_futex_waitv()
linux commit ea7c45fde5aa3e761aaddb7902a31a95cb120e7b
futex,arm: Wire up sys_futex_waitv()
linux commit b3ff2881ba18b852f79f5476d7631940071f1adb
MIPS: syscalls: Wire up futex_waitv syscall
linux commit 6c122360cf2f4c5a856fcbd79b4485b7baec942a
s390: wire up sys_futex_waitv system call
linux commit a0eb2da92b715d0c97b96b09979689ea09faefe6
futex: Wireup futex_waitv syscall
see
linux commit 884a7e5964e06ed93c7771c0d7cf19c09a8946f1
mm: introduce process_mrelease system call
linux commit dce49103962840dd61423d7627748d6c558d58c5
mm: wire up syscall process_mrelease
see
linux commit 7bb7f2ac24a028b20fca466b9633847b289b156a
arch, mm: wire up memfd_secret system call where relevant
linux commit 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49
mm: introduce memfd_secret system call to create "secret" memory areas
linux commit b633896314c0f78f2b4eb7b19a530d68f2a35445
tools headers UAPI: Sync s390 syscall table file that wires up the
memfd_secret syscall
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.
Undefine any previous __STDC_UTF_{16,32}__ macros before defining
them to prenvent any warnings of redefining macros.
This happens as a result of some compiler versions defining the macros
themselves.
Linux and most systems do not have symlink permissions, but some
systems, including MacOS, do, and creation of the symlink with umask
set to 0777 makes the symlink inaccessible on such systems.
clear umask when making a symlink so that the behavior is uniform.
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")
Note: Some relocation types were only used by binutils and
accidentally exposed to previous versions of psABI. One of the values
has been reused by GOT32_PCREL.
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.
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.
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.
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.
These were overlooked when DT_RELR was added in commit
d32dadd60e, potentially breaking
software that treats presence of the DT_RELR macro as implying they
exist.
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.
