since commit e1a51185ce, popen obeys an
obscure historical requirement to implement a sort of pseudo-cloexec
behavior for other pipe streams obtained by popen. but since popen
uses posix_spawn (and thereby posix_spawn file actions) internally,
the time of check for other pipe streams is separated from the time of
closure.
this was intended to be addressed by popen holding the open file list
lock across posix_spawn, but pclose (via fclose) closes the file
descriptor before taking the open file list lock, only using the lock
for updating the linked list pointers. this is to avoid serializing
fclose operations across the entire process, since in general close
may be a blocking operation.
multiple solutions to this problem were considered, but the simplest
and least invasive is conditionally taking the open file list lock
early for popen streams -- that is, for FILE streams where the
pipe_pid member is nonzero. since the file descriptor refers to a
pipe, closing it is a simple, nonblocking operation, and the only cost
is the time spent entering and leaving kernelspace while the lock is
held.
since individual FILE locks cannot be held while taking the open file
list lock (this would violate lock order protocol and produce
deadlocks), the FILE lock must be released after fflush but before the
ofl lock is taken. there is no point in retaking the lock afterwards,
since the FILE pointer is no longer valid and any further use by the
application would be undefined. so, simply let fflush do the locking.
note that the early return path (F_PERM) is not reachable for popen
streams, only for stdin/stdout/stderr, which are always normal FILEs.
thus, it does not provide a code path to return with the ofl lock
still held.
nanosleep is a time32 syscall which riscv32 lacks by being natively
time64. the erroneous macro being present did not break anything libc
internal, because SYS_nanosleep is never used in the natively-time64
path, but i could in theory cause applications to wrongly attempt to
use it if they do their own syscalls. it has wrongly been there since
the riscv32 port was added.
close_range and quotactl_fd were somehow omitted in commit
8432d16a46.
LDBL_* macros were not defined in logbl.
the code happens to be correct without them, but when the long double
format matches double the intention was to tail call logb.
the expression LDBL_MANT_DIG/4+1 was intended to represent the number
of hex digits which can be significant, after which all that matters
to the result, regardless of rounding mode, is whether any part of the
tail is nonzero.
however, the expression LDBL_MANT_DIG/4 is only exact for ld80 archs.
for ld64 and ld128, the truncation of the remainder caused one too few
digits to be processed, producing incorrect rounding.
for ld128 archs, only strtold and scanf's %La conversion specifier
were affected; doubles and floats still had plenty of trailing digits
to yield a correct final rounding. but for ld64 archs, the number of
digits processed were insufficient for double, and could affect any
code using strtod or scanf's %a.
for ld64 archs, 0x1.111111111111281 produces an incorrect rounding
down, and 0x1.11111111111111 produces an incorrect rounding up.
for ld128 archs, the inputs 0x1.111111111111111111111111111281 and
0x1.11111111111111111111111111111 behave respectively.
rounding up in the expression for the number of hex digits needed
produces correct results.
aligned allocations are handled by over-allocating enough to ensure an
aligned subrange exists and framing the usable space to that subrange.
the framing can only handle offsets up to a 32-bit multiple of the
allocation UNIT (16 bytes), and aligned_alloc correctly checks for and
rejects larger alignments.
however, when get_meta reads back the offset, the type of the variable
and everything else in the expression where it's used was int, not
size_t, and offset*UNIT can overflow. modulo the "anything can happen"
aspect of overflow being undefined, a clean trap will occur and the
program will terminate. this would happen on any call to free,
realloc, or malloc_usable_size call on the large-alignment object.
switch the type of offset in get_meta from int to size_t. this has
been checked not to break any of the subsequent assertions:
- assert(offset > 0xffff) was wrongly rejecting offsets that would be
interpreted as negative when converted to signed int. this is fixed
by processing offset as unsigned.
- the check against the slot boundaries switches which assert would
catch values that were previously interpreted as negative, but the
net effect is the same.
- the check against maplen was already converting to unsigned long due
to the 4096UL in the expression. in doing so, it was incorrectly
sign-extending the offset rather than zero-extending. this is fixed
by using unsigned type to begin with.
in addition, take the opportunity to trap on offsets were offset*UNIT
would overflow. this cannot happen on 64-bit archs (and it should be
optimized out by the compiler there), but it's an additional signal we
can use to catch out-of-bounds writes on 32-bit ones. and the check
only happens when operating on extremely large, overaligned objects,
so the relative cost of checking is essentially zero.
this code path potentially runs prior to stage 3, with thread-local
storgae and thus errno unavailable. for this reason, commit
63c67053a3 removed the call to the
mprotect function and replaced it with a __syscall operation that
bypasses errno.
however, this left the error message printing (which is only reachable
in stage 3 and thus can safely access errno) with no error code for
the %m format specifier to use.
introduce a new set_errno function pointer that points to a no-op
until stage 3. this is analogous to the error function pointer
introduced in commit d16d7b1099.
commit d2e061a2bd wrongly added this
case based on a misreading of the standard text regarding null
termination in write/update modes. apparently, the condition "if it
fits" was interpreted as only applying to update modes, despite the
words "or for writing only" appearing.
if shl() or shr() are called with n==8*sizeof(size_t), n is adjusted
to 0. the shift by (sizeof(size_t) * 8 - n) that then follows will
consequently shift by the width of size_t, which is UB and in practice
produces an incorrect result.
return early in this case. the bitvector p was already shifted by the
required amount.
while the root cause of CVE-2026-40200 was a faulty ctz primitive, the
fallout of the bug would have been limited to erroneous sorting or
infinite loop if not for the stores to a stack-based array that
depended on trusting invariants in order not to go out of bounds.
increase the size of the array to a power of two so that we can mask
indices into it to force them into range. in the absence of any
further bug, the masking is a no-op, but it does not have any
measurable performance cost, and it makes spatial memory safety
trivial to prove (and for readers not familiar with the algorithms to
trust).
the pntz function, implementing a "count trailing zeros" variant for a
bit vector consisting of two size_t words, erroneously returned zero
rather than the number of bits in the low word when the first bit set
was the low bit of the high word.
as a result, a loop in the trinkle function which should have a
guaranteed small bound on the number of iterations, could run
unboundedly, thereby overflowing a stack-based working-space array
which was sized for the bound.
CVE-2026-40200 has been assigned for this issue.
use of || forces the caller to boolean-normalize the result of
iswalpha to 0 or 1, requiring code after the call returns and thus
precluding a tail call.
since this isn't actually needed, don't write it that way.
in order to implement the "UTF" aspect of gb18030 (ability to
represent arbitrary unicode characters not present in the 2-byte
mapping), we have to apply the index obtained from the encoded 4-byte
sequence into the set of unmapped characters. this was done by
scanning repeatedly over the table of mapped characters and counting
off mapped characters below a running index by which to adjust the
running index by on each iteration. this iterative process eventually
leaves us with the value of the Nth unmapped character replacing the
index, but depending on which particular character that is, the number
of iterations needed to find it can be in the tens of thousands, and
each iteration traverses the whole 126x190 table in the inner loop.
this can lead to run times exceeding an entire second per character on
moderate-speed machines.
on top of that, the transformation logic produced wrong results for
BMP characters above the the surrogate range, as a result of not
correctly accounting for it being excluded, and for characters outside
the BMP, as a result of a misunderstanding of how gb18030 encodes
them.
this patch replaces the unmapped character lookup with a single linear
search of a list of unmapped ranges. there are only 206 such ranges,
and these are permanently assigned and unchangeable as a consequence
of the character encoding having to be stable, so a simple array of
16-bit start/length values for each range consumes only 824 bytes, a
very reasonable size cost here.
this new table accounts for the previously-incorrect surrogate
handling, and non-BMP characters are handled correctly by a single
offset, without the need for any unmapped-range search.
there are still a small number of mappings that are incorrect due to
late changes made in the definition of gb18030, swapping PUA
codepoints with proper Unicode characters. correcting these requires a
postprocessing step that will be added later.
in BRE \n matches the nth subexpression, but regcomp did not check if
the nth subexpression was complete or not, only that there were more
subexpressions overall than the largest backref.
fix regcomp to error if the referenced subexpression is incomplete.
the bug could cause an infinite loop in regexec:
regcomp(&re, "\\(^a*\\1\\)*", 0);
regexec(&re, "aa", 0, 0, 0);
since BRE has backreferences, any application accepting a BRE from
untrusted sources is already vulnerable to an attacker-controlled
near-infinite (exponential-time) loop, but this particular case where
the loop is actually infinite can and should be avoided.
ERE is not affected since the language an ERE describes is actually
regular.
Reported-by: Simon Resch <simon.resch@code-intelligence.com>
there are three issues here:
1. if tzset has not been called (explicitly or implicitly), the
tzname[] array will contain null pointers, and the dereference to
compare against them has undefined behavior (and will fault).
2. access to tzname[] was performed without the timezone lock held.
this resulted in a data race if the timezone is concurrently changed
from another thread.
3. due to unintended signedness of the types, the open-coded isalpha
in the non-matching case was wrong and would continue past null
termination.
to fix the first two issues, the body of the %Z conversion is moved to
__tz.c where it has access to locking, and null checks are added.
there is probably an argument to be made that the equivalent of tzset
should happen here, but POSIX does not specify that to happen, so in
the absence of an interpretation adding such an allowance or
requirement, it is not done.
the third issue is fixed just by using the existing isalpha macro.
In __res_msend_rc(), the IPv6-disabled fallback check uses conf->ns[nns]
inside a loop controlled by i, so it tests a fixed slot instead of
walking configured nameservers. This reads one past the array's size.
Use conf->ns[i] so the loop correctly detects whether all configured
nameservers are IPv6-only.
on some kernel builds, the vdso exports symbols with DT_GNU_HASH but
omits DT_HASH, causing the vdso not to get used and for clock_gettime
to fall back to using a syscall.
our vdso resolver does not use the hash table anyway, but does need
the symbol count from the standard sysv hash table. if it's missing,
use the GNU hashtable to calculate the number of symbols.
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.
Add madvise flag which performs a best-effort synchronous
collapse of the native pages mapped by the memory range
into Transparent Huge Pages (THPs)
see
linux commit 7d8faaf155454f8798ec56404faca29a82689c77
mm/madvise: introduce MADV_COLLAPSE sync hugepage collapse
this flag works like MADV_DONTNEED but also applies to locked memory
ranges.
see
linux commit 9457056ac426e5ed0671356509c8dcce69f8dee0
mm: madvise: MADV_DONTNEED_LOCKED
Add madvise flags to populate(prefault) page tables
see
linux commit 4ca9b3859dac14bbef0c27d00667bb5b10917adb
mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault page tables
These new LoongArch reloc types(101 to 126) have been added in
LoongArch psABI v2.30 and NT_LOONGARCH_HW_BREAK/NT_LOONGARCH_HW_WATCH
sync with Linux 6.12 elf.h.
Add two missing syscalls from v5.14 and new syscalls from v6.4 .. v6.19
add __NR_quotactl_fd from linux v5.14 see
linux commit 9dfa23c8de925041b7b45637a1a80a98a22f19dd
quota: Add mountpath based quota support
linux commit fa8b90070a80bb1a3042b4b25af4b3ee2c4c27e1
quota: wire up quotactl_path
linux commit 64c2c2c62f92339b176ea24403d8db16db36f9e6
quota: Change quotactl_path() systcall to an fd-based one
add __NR_memfd_secret from linux v5.14 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
note: was already added on x86 and s390, now on aarch64 and riscv*.
add riscv __NR_riscv_hwprobe from linux v6.4 see
linux commit ea3de9ce8aa280c5175c835bd3e94a3a9b814b74
RISC-V: Add a syscall for HW probing
add x86_64 only map_shadow_stack syscall from linux v6.6 see
linux commit c35559f94ebc3e3bc82e56e07161bb5986cd9761
x86/shstk: Introduce map_shadow_stack syscall
add map_shadow_stack syscall from linux v6.7 see
linux commit 2fd0ebad27bcd4c8fc61c61a98d4283c47054bcf
arch: Reserve map_shadow_stack() syscall number for all architectures
add futex_* syscalls from linux v6.7 see
linux commit 9f6c532f59b20580acf8ede9409c9b8dce6e74e1
futex: Add sys_futex_wake()
linux commit cb8c4312afca1b2dc64107e7e7cea81911055612
futex: Add sys_futex_wait()
linux commit 0f4b5f972216782a4acb1ae00dcb55173847c2ff
futex: Add sys_futex_requeue()
add statmount, listmount syscalls from linux v6.8 see
linux commit d8b0f5465012538cc4bb10ddc4affadbab73465b
wire up syscalls for statmount/listmount
linux commit b4c2bea8ceaa50cd42a8f73667389d801a3ecf2d
add listmount(2) syscall
linux commit 46eae99ef73302f9fb3dddcd67c374b3dffe8fd6
add statmount(2) syscall
add lsm_* syscalls from linux v6.8 see
linux commit 5f42375904b08890f2e8e7cd955c5bf0c2c0d05a
LSM: wireup Linux Security Module syscalls
linux commit ad4aff9ec25f400608283c10d634cc4eeda83a02
LSM: Create lsm_list_modules system call
linux commit a04a1198088a1378d0389c250cc684f649bcc91e
LSM: syscalls for current process attributes
add mseal syscall from linux v6.10 see
linux commit ff388fe5c481d39cc0a5940d1ad46f7920f1d646
mseal: wire up mseal syscall
on sh add sync_file_range2 from linux v6.10 see
linux commit 30766f1105d6d2459c3b9fe34a3e52b637a72950
sh: rework sync_file_range ABI
on x86 add uretprobe from linux v6.11 see
linux commit 54233a4254036efca91b9bffbd398ecf39e90555
uretprobe: change syscall number, again
add *xattrat syscalls from linux v6.13 see
linux commit 6140be90ec70c39fa844741ca3cc807dd0866394
fs/xattr: add *at family syscalls
add open_tree_attr from linux v6.15 see
linux commit c4a16820d90199409c9bf01c4f794e1e9e8d8fd8
fs: add open_tree_attr()
add file_{get,set}attr from linux v6.17 see
linux commit be7efb2d20d67f334a7de2aef77ae6c69367e646
fs: introduce file_getattr and file_setattr syscalls
on x86 add uprobe from linux v6.18 see
linux commit 56101b69c9190667f473b9f93f8b6d8209aaa816
uprobes/x86: Add uprobe syscall to speed up uprobe
add listns from linux v6.19 see
linux commit b36d4b6aa88ef039647228b98c59a875e92f8c8e
arch: hookup listns() system call
sll_addr is a member of sockaddr_ll, but it is misspelled as
ssl_addr in comment.
Please cc me back when reply.
Signed-off-by: RocketDev <marocketbd@gmail.com>
The LOCK_OBJ_DEF macro is used with a trailing semicolon. However,
since the macro definition ends with the closing brace of a function
definition, the ISO C grammar does not allow an extra semicolon.
To fix this, swap the order of the two definitions, and drop the
semicolon from the __malloc_lock declaration.
This fixes an error in 6af4f25b899e89e4b91f8c197ae5a6ce04bcce7b: The
r0 register is special in addressing modes on s390x and is interpreted
as constant zero, i.e. lg %r5, 8(%r0) would effectively become lg %r5,
8. So care should be taken to never use r0 as an address register in
s390x assembly.
commit f96e47a261 introduced a new
overflow past the end of the base-1e9 buffer for floating point to
decimal conversion while fixing a different overflow below the start
of the buffer.
this bug has not been present in any release, and has not been
analyzed in depth for security considerations.
the root cause of the bug, incorrect size accounting for the mantissa,
long predates the above commit, but was only exposed once the
excessive offset causing overflow in the other direction was removed.
the number of slots for expanding the mantissa was computed as if each
slot could peel off at least 29 bits. this would be true if the
mantissa were placed and expanded to the left of the radix point, but
we don't do that because it would require repeated fmod and division.
instead, we start the mantissa with 29 bits to the left of the radix
point, so that they can be peeled off by conversion to integer and
subtraction, followed by a multiplication by 1e9 to prepare for the
next iteration. so while the first slot peels 29 bits, advancing to
the next slot adds back somewhere between 20 and 21 bits: the length
of the mantissa of 1e9. this means we need to account for a slot for
every 8 bits of mantissa past the initial 29.
add a comment to that effect and adjust the max_mant_slots formula.
per the psABI, floating point register contents beyond the register
size of the targeted ABI variant are never call-saved, so no
hwcap-conditional logic is needed here and the assembly-time
conditions are based purely on ABI variant macros, not the targeted
ISA level.
the ctr and xer special registers are call-clobbered and
syscall-clobbered. failure to include them in the clobber list may
result in wrong code that attempts to use a value which is no longer
present in the register after the syscall. this has been reported to
manifest newly with gcc 15.
v4-compatible addresses in ipv6 are a deprecated feature where the
high 96 bits are all zero and an ipv4 address is stored in the low
32 bits. however, since :: and ::1 are the unspecified and loopback
addresses, these two particular values are excluded from the
definition of the v4-compat class.
our version of the macro incorrectly assessed this condition by
checking only the high 96 and low 8 bits. this incorrectly excluded
the v4compat version of any ipv4 address ending in .1, not just ::1.
rather than writing out non-obvious or error-prone conditions on the
individual address bytes, just express the "not :: or ::1" condition
naturally using the existing IN6_IS_ADDR_UNSPECIFIED and
IN6_IS_ADDR_LOOPBACK macros, after checking that the high 96 bits are
all zero. any vaguely reasonable compiler will collapse out the
redundant tests of the upper bits as part of CSE.
as stated in the comment added, the ABI for SME requires libc to be
aware of and support the extension to the register file. this is
necessary to handle lazy saving correctly across setjmp/longjmp, and
on older kernels, in order not to introduce memory corruption bugs
that may be exploitable vulnerabilities when creating new threads.
previously, we did not expose __getauxval, the interface libgcc uses
to determine runtime availability of SME, so it was not usable when
following the intended ABI. since commit
ab4635fba6 has now exposed this
interface, a mitigation is needed to ensure SME is not used
unless/until we have proper support for it.
while SME is the current hwcap feature that needs this treatment,
as-yet-undefined hwcap bits are also masked in case other new cpu
features have similar ABI issues. this could be re-evaluated at some
point in the future.
for now, the masking is only on aarch64. arguably it should be
considered for all archs, but whether it's needed is really a matter
of how ABI policy & stability are handled by the maintainers of the
arch psABI, and aarch64 is the one that's demonstrated a necessity. if
it turns out something like this is needed for more/all archs, making
a generalized framework for it would make sense. for now, it's stuffed
into __set_thread_area the same way atomics detection is stuffed there
for 32-bit arm and sh, as it's a convenient point for "arch-specific
early setup code" without invasive changes.
this change both aligns with the intended future direction for most
assembly usage, and makes it possible to add arch-specific setup logic
based on hwcaps like we have for 32-bit arm.
commit 572a2e2eb9 adjusted the buffer
for decimal conversion to be a VLA that only uses the full size needed
for long double when the argument type was long double. however, it
failed to update a later expression for the positioning within the
buffer, which still used a fixed offset of LDBL_MANT_DIG. this caused
doubles with a large positive exponent to overflow below the start of
the array, producing wrong output and potentially runaway wrong
execution.
this bug has not been present in any release, and has not been
analyzed in depth for security considerations.
it turns out the original buffer offset expression involving
LDBL_MANT_DIG was incorrect as well, and only worked because the space
reserved for expanding the exponent is roughly 3 times the size it
needs to be when the exponent is positive, leaving plenty of extra
space to compensate for the error. the actual offset should be in
base-1000000000 slot units, not bits, and numerically equal to the
number of slots that were previously allocated for mantissa expansion.
in order to ensure consistency and make the code more comprehensible,
commented subexpressions are replaced by intermediate named variables,
and the newly introduced max_mant_slots is used for both the
allocation and the buffer offset adjustment. the included +1 term
accounts for a trailing zero slot that's always emitted.
This is needed so that libgcc can access AT_HWCAP without violating
link namespace rules.
Internally musl already used __getauxval symbol for the same reason,
we just remove the hidden marking.
Linux kernel commit ee988c11acf6f9464b7b44e9a091bf6afb3b3a49 added two
new HWCAP bits: one for ARCH_3_1, which is the Power10 ISA revision, and
one for MMA, which is the optional Matrix Multiply Assist extension.
When buffering on a FILE is disabled we still send both iovecs, even
though the first one is always empty. Clean things up by skipping the
empty iovec instead.
POSIX 2024 added a requirement that mbsnrtowcs, like mbrtowc, consume
any final partial character and store it in the mbstate_t object
before returning. this was previously unspecified but documented as a
potential future change.
an internal mbstate_t object is added for the case where the argument
is a null pointer. previously this was not needed since no operations
could modify the internal object and not processing it at all gave the
same behavior "as if" there were an internal object.
Rich Felker
Szabolcs Nagy
Luca Kellermann
Alex Rønne Petersen
Sertonix
Liam Wachter
Tomáš Hulata
Michal Biesek
Xing Li
JianTao Shan
Jingyun Hua
RocketDev
Michael Forney
J. Neuschäfer
A. Wilcox
Casey Connolly