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.

whether fenv is supported depends on the ABI, not whether the target
cpu ISA level has floating point support.

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.