PR port-sparc64/60428
Just return instead of asserting that devhandle is DEVHANDLE_TYPE_OF.
This happens for USB disks (sd @ scsibus @ umass @ @ uhub @ usb) which
are not enumerated by the firmware.
Original patch from riastradh@ .
Apply the same for wd and fc-al as well.
Verify signal delivery preserves various FPU state.
Should also test AVX512 but I'm not sure I have hardware handy to do
this right now and qemu doesn't emulate it, as far as I know! TBD.
(Plus: there's umpteen different cpuid feature bits to consider,
annoyingly, and that means a lot of manual reading to sort through
them.)
PR kern/60426: Signal handler corrupts AVX (YMM) registers
dev/ic/mpt_netbsd.c - another clang appeasement attempt
and change all strncat() (which were not what was intended)
into strlcat() which implement the original intent.
import libevent-2.1.13 (previous was 2.1.12)
Changes in version 2.1.13-stable (01 July 2026)
This release contains several security fixes, affecting users of the
following modules: evbuffer, bufferevent, evtag, evrpc, evdns, evhttp.
If you have a program that uses one of those modules,
or if you distribute libevent, you should upgrade.
Additionally, this release backports some small modernizations to
the libevent codebase, to aid in compiling with the compilers
released over the last few years.
Security Fixes (evtag, evrpc):
- Fix an out-of-bounds read in decode_tag_internal.
(Found by @Brubbish. GHSA-fj29-64w6-73h6)
- Fix an integer overflow in evtag_unmarshal_header.
(Found by @Brubbish. GHSA-45c6-qx49-89m8)
[31 lines not shown]
PR lib/60324 - isolate descent into lib
Since no-one seems interested in implementing a better fix
than this for the issue in the PR which (sometimes) breaks
the builds, simply do the easiest possible thing which will
avoid the observed symptoms.
Don't allow builds in lib and external to happen in parallel
by simply isolating the descent into lib (there is a LOT to
do in there). Don't start anything else until that is done.
If anyone would like to find a different workable solution than
this one, please go ahead.
sbin/efi - avoid generating invalid UTF-8
Strings in UEFI are all made up of 16 bit chars, which are defined in the
UEFI standard to be UCS-2 (despite that format having been deprecated for
decades - replaced by UTF-16).
UCS-2 allowed for just 65536 code points (hence 16 bit storage). UTF-16
defines a block of 8192 of the available code-points to be surrogates, 4096
of them high surrogates, the other 4096 low surrogates, always to be used
as a pair, high then low.
Each surrogate of a pair provides 10 data bits, combining them together gives
a 20 bit value, which is used by UTF-16 to represent the code point values
from 0x10000 -> 0x10FFFF. By doing that they (for all time) reserved the
8192 surrogate code points (those with values from 0xD800 to 0xDFFF (incl)),
regardless of the format in which they're encoded, as being invalid, except
when used as part of a surrogate pair in UTF-16.
So, since UCS-2 had no surrogates (not really) and is (was) defined to
[16 lines not shown]
