about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* use new SYS_fchmodat2 syscall to implement fchmodat with flagsGaël PORTAY2024-02-221-1/+4
| | | | | | | | | | | commit 0dc4824479e357a3e23a02d35527e23fca920343 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.
* bits/syscall.h: add __NR_fchmodat2 from linux v6.6Gaël PORTAY2024-02-2216-0/+16
| | | | | | | | | | | 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
* remove flag argument from fchmodat syscallGaël PORTAY2024-02-221-1/+1
| | | | linux's does not have the flag argument for fchmodat syscall.
* bits/syscall.h: add cachestat from linux v6.4Gaël PORTAY2024-02-2216-0/+16
| | | | | | | | | | see linux commit cf264e1329fb0307e044f7675849f9f38b44c11a cachestat: implement cachestat syscall linux commit 946e697c69ffeeefdd84dad90eac307284df46be cachestat: wire up cachestat for other architectures
* bits/syscall.h: add set_mempolicy_home_node from linux v5.17Gaël PORTAY2024-02-2216-0/+16
| | | | | | | | | | see linux commit c6018b4b254971863bd0ad36bb5e7d0fa0f0ddb0 mm/mempolicy: add set_mempolicy_home_node syscall linux commit 21b084fdf2a49ca1634e8e360e9ab6f9ff0dee11 mm/mempolicy: wire up syscall set_mempolicy_home_node
* bits/syscall.h: add futex_waitv from linux v5.16Gaël PORTAY2024-02-2216-0/+16
| | | | | | | | | | | | | | | | | | | 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
* bits/syscall.h: add process_mrelease from linux v5.15Rich Felker2024-02-2216-0/+16
| | | | | | | | | | see linux commit 884a7e5964e06ed93c7771c0d7cf19c09a8946f1 mm: introduce process_mrelease system call linux commit dce49103962840dd61423d7627748d6c558d58c5 mm: wire up syscall process_mrelease
* bits/syscall.h: add memfd_secret from linux v5.14Gaël PORTAY2024-02-224-0/+4
| | | | | | | | | | | | | | 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
* add framework to support archs without a native wait4 syscallRich Felker2024-02-226-4/+71
| | | | | | | | | | 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.
* sh: fix sigsetjmp corrupting call-saved register r8Rich Felker2024-02-171-1/+1
| | | | | due to incorrect base address register when attempting to reload the saved value of r8, the caller's value of r8 was not preserved.
* add loongarch64 portHongliang Wang2024-02-1629-1/+1116
| | | | | | | | | | | | | Author: Xiaojuan Zhai <zhaixiaojuan@loongson.cn> Author: Meidan Li <limeidan@loongson.cn> Author: Guoqi Chen <chenguoqi@loongson.cn> Author: Xiaolin Zhao <zhaoxiaolin@loongson.cn> Author: Fan peng <fanpeng@loongson.cn> Author: Jiantao Shan <shanjiantao@loongson.cn> Author: Xuhui Qiang <qiangxuhui@loongson.cn> Author: Jingyun Hua <huajingyun@loongson.cn> Author: Liu xue <liuxue@loongson.cn> Author: Hongliang Wang <wanghongliang@loongson.cn>
* strftime: fix breakage in last change (uninitialized pointer access)Rich Felker2024-02-161-1/+6
| | | | | | | | | | commit f47a5d400b8ffa26cfc5b345dbff52fec94ac7f3 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.
* fix erroneous feature test macro check for ppollRich Felker2024-02-081-2/+2
| | | | | | | | | commit f247462b0831cbf163e976ee9a909748c674b88b 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.
* syslog: use C locale for timestamp generationRich Felker2024-02-071-1/+2
| | | | | | | | | | | | | 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.
* stdc-predef.h: prevent redefining __STDC_UTF_{16,32}__ macrosJules Maselbas2024-02-031-0/+3
| | | | | | | | 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.
* riscv: add TLSDESC supportRich Felker2024-02-032-0/+33
|
* install.sh: avoid creating symlinks with restricted permissionsTim Cuthbertson2024-02-031-0/+2
| | | | | | | | 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.
* sqrtl: fix invalid use of a non-constant-expression as static initializerRich Felker2024-02-031-2/+2
| | | | | | | | | 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.
* riscv: correct symbol version of __vdso_flush_icachegns2024-02-031-1/+1
| | | | | | | | Previously, __riscv_flush_icache would not work correctly as __vdso_flush_icache had a wrong symbol version. Fix this by correcting symbol version. Fixes: 0a48860c27a8 ("add riscv64 architecture support")
* elf.h: add NT_RISCV_CSR and NT_RISCV_VECTOR constantsElliott Hughes2024-02-031-0/+2
| | | | | See Linux commit 9300f00439743c4a34d735e1a27118eb68a1504e ("RISC-V: Add ptrace support for vectors").
* elf.h: update RISC-V relocation typesFangrui Song2024-02-031-6/+10
| | | | | | 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.
* add preadv2 and pwritev2 syscall wrappers, flag value macrosRich Felker2024-01-253-0/+41
|
* expose ppoll in default feature profileRich Felker2024-01-212-3/+3
| | | | | | | 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.
* move ppoll from src/linux to src/select reflecting future standardizationRich Felker2024-01-211-0/+0
| | | | | | 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.
* remove INT_MAX limit on the n argument to snprintf/swprintfRich Felker2024-01-172-8/+0
| | | | | | | | | | | | | | | | 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.
* strftime: don't attempt to parse field width without seeing a digitRich Felker2023-11-211-1/+2
| | | | | | 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.
* mntent: fields are delimited only by tabs or spaces, not general whitespaceRich Felker2023-11-161-1/+1
| | | | | | this matters because the kernel-provided mtab only escapes tabs, spaces, newlines, and backslashes. it leaves carriage returns, form feeds, and vertical tabs literal.
* mntent: unescape octal sequencesq662023-11-161-4/+40
| | | | | | 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.
* ldso: fix TLSDESC addend processing on archs with backwards descriptorsRich Felker2023-11-061-1/+1
| | | | | | | | | | 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.
* ldso: convert TLSDESC_BACKWARDS from "#ifdef" to "if" logicRich Felker2023-11-063-6/+10
| | | | | this style is preferred because it allows the code to be compile-checked even on archs where it is not used.
* byte-based printf family: emit a nul byte for %lc with argument zeroRich Felker2023-11-061-0/+2
| | | | | | | | 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.
* remove arbitrary limit from dns result parsingQuentin Rameau2023-11-061-1/+0
| | | | | | | | | | 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.
* pass AT_NO_AUTOMOUNT when emulating fstatat via statxAlexey Izbyshev2023-11-061-0/+1
| | | | | | | | | | | 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.
* __year_to_secs: fix dangling pointerAlex Xu (Hello71)2023-11-061-2/+2
| | | | | The lifetime of the compound literal ends after the "if" statement's implicit block. gcc also warns about this.
* timer_create: volatile static -> static volatileAlex Xu (Hello71)2023-11-061-1/+1
| | | | | | | | | | 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.
* ensure valid setxid return value in an unexpected error caseMarkus Wichmann2023-11-061-1/+1
| | | | | | | | | | | | 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().
* synccall: add separate exit_sem to fix thread release logic bugMarkus Wichmann2023-11-061-3/+5
| | | | | | | | | | | | | | | | | 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.
* ldso: use __ehdr_start if available to locate its own ELF headersRich Felker2023-11-061-1/+3
| | | | | | | | | | | | | 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.
* remove non-prototype declaration of basename from string.hRich Felker2023-11-061-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | commit 37bb3cce4598c19288628e675eaf1cda6e96958f 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 06aec8d7152dfb8360cb7ed9b3d7215ca0b0b500, 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.
* elf.h: add typedefs for Elf64_Relr and Elf32_RelrViolet Purcell2023-11-061-0/+5
| | | | | | | These were overlooked when DT_RELR was added in commit d32dadd60efb9d3b255351a3b532f8e4c3dd0db1, potentially breaking software that treats presence of the DT_RELR macro as implying they exist.
* glob: fix wrong return code when aborting before any matchesRich Felker2023-08-241-1/+1
| | | | | | | | | | 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.
* statvfs: allocate spare for f_typeнаб2023-08-192-1/+3
| | | | | | | | | | | | | | | | | | | | 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 6567db65f495cf7c11f5c1e60a3e54543d5a69bc (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.
* math: fix ld80 powl(x,huge) and powl(LDBL_MAX,small)Szabolcs Nagy2023-08-191-13/+21
| | | | | | | | | | | | | | 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).
* math: fix ld80 acoshl(x) for x < 0Szabolcs Nagy2023-08-191-3/+7
| | | | | | | | | | | | 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.
* fix rejection of dns responses with pointers past 512 byte offsetRich Felker2023-07-171-2/+2
| | | | | | | | | | | | 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 51d4669fb97782f6a66606da852b5afd49a08001 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.
* dns stub resolver: increase buffer size to handle chained CNAMEsRich Felker2023-07-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | in the event of chained CNAMEs, the answer to a query will contain the entire CNAME chain, not just one CNAME record. previously, the answer buffer size had been chosen to admit a maximal-length CNAME, but only one. a moderate-length chain could fill the available 768 bytes leaving no room for an actual address answering the query. while the DNS RFCs do not specify any limit on the length of a CNAME chain, or any reasonable behavior is the chain exceeds the entire 64k possible message size, actual recursive servers have to impose a limit, and a such, for all practical purposes, chains longer than this limit are not usable. it turns out BIND has a hard-coded limit of 16, and Unbound has a default limit of 11. assuming the recursive server makes use of "compression" (pointers), each maximal-length CNAME record takes at most 268 bytes, and thus any chain up to length 16 fits in at most 4288 bytes. this patch increases the answer buffer size to preserve the original intent of having 512 bytes available for address answers, plus space needed for a maximal CNAME chain, for a total of 4800 bytes. the resulting size of 9600 bytes for two queries (A+AAAA) is still well within what is reasonable to place in automatic storage.
* printf core: fix gratuitous integer formatting buffer sizeRich Felker2023-06-121-1/+1
| | | | | | | | | | | the extra terms 3 and LDBL_MANT_DIG/4 are remnants of a proto-musl implementation of printf where the sign/prefix and floating point conversions were performed naively into this buffer. having them there obscures the actual intended buffer size (sufficient to hold between 2 and 3 octal digits per byte, rounded up to 3 for simplicity) and interferes with upcoming work to add C2x binary formats which would otherwise be stuck having to explain a similar fix to buffer size as part of an unrelated change.
* all printf variants: fix argument type handling for %c and %lcRich Felker2023-06-122-4/+4
| | | | | | | | | | | | | | | | %c takes an argument of type int, not char, and %lc/%C takes an argument of type wint_t (unsigned), not int. for most cases, this makes no practical difference, but since wide printf variants convert narrow %c format specifiers via btowc, interpreting the promoted-to-int unsigned char value passed in as a (signed, on most archs) char causes 255 to get collapsed to EOF and interpreted as such by btowc. this is only relevant in the byte-based C locale, so prior to commit f22a9edaf8a6f2ca1d314d18b3785558279a5c03, there was no observable distinction in behavior. for UTF-8, all bytes which might be negative when interpreted as char are encoding errors when used with %c/btowc.
* fix public clone function to be safe and usable by applicationsRich Felker2023-06-013-16/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the clone() function has been effectively unusable since it was added, due to producing a child process with inconsistent state. in particular, the child process's thread structure still contains the tid, thread list pointers, thread count, and robust list for the parent. this will cause malfunction in interfaces that attempt to use the tid or thread list, some of which are specified to be async-signal-safe. this patch attempts to make clone() consistent in a _Fork-like sense. as in _Fork, when the parent process is multi-threaded, the child process inherits an async-signal context where it cannot call AS-unsafe functions, but its context is now intended to be safe for calling AS-safe functions. making clone fork-like would also be a future option, if it turns out that this is what makes sense to applications, but it's not done at this time because the changes would be more invasive. in the case where the CLONE_VM flag is used, clone is only vfork-like, not _Fork-like. in particular, the child will see itself as having the parent's tid, and cannot safely call any libc functions but one of the exec family or _exit. handling of flags and variadic arguments is also changed so that arguments are only consumed with flags that indicate their presence, and so that flags which produce an inconsistent state are disallowed (reported as EINVAL). in particular, all libc functions carry a contract that they are only callable with ABI requirements met, which includes having a valid thread pointer to a thread structure that's unique within the process, and whose contents are opaque and only able to be setup internally by the implementation. the only way for an application to use flags that violate these requirements without executing any libc code is to perform the syscall from application-provided asm.
* fix broken thread list unlocking after forkRich Felker2023-06-011-1/+1
| | | | | | | | | | | apparently Linux clears the registered exit futex address on fork. this means that, if after forking the child process becomes multithreaded and the original thread exits, the thread list will never be unlocked, and future attempts to use the thread list will deadlock. re-register the exit futex address after _Fork in the child to ensure that it's preserved.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-04 21:04:54 +0000