Avoid sleeping while recording SEM_UNDO information
sys_semop(), by way of semundo_adjust() and semu_alloc(), could sleep in
pool_get(PR_WAITOK) after it had already applied the semaphore operations.
Another process can remove the set with IPC_RMID while we sleep; we then write
sempid and sem_otime through the freed semid_ds_kern and sem_base, and record
an undo entry for a set semundo_clear() has already swept, which panics
semexit() when the process exits.
This was introduced as a fallback in rev 1.14, after moving the
structures from a static array to a pool made the allocation able to
fail at all. semop(2) documents ENOSPC, so drop the fallback with the
extra complexity to work around the sleep.
semundo_adjust() must then stop freeing an emptied structure in the middle of
an operation: sys_semop()'s rollback can need it again, and re-creating it
there is allowed to fail, which is a panic. Keep it until done2. That also
takes a second sleeping pool_put() out of the done: region.
[7 lines not shown]
vmd(8): Add Checksum Offload for guests.
With tweaks from dlg@, claudio@ and dv@.
Tested with Linux and OpenBSD guests with routing, bridging and vlan(4).
Also tested by bluhm@.
Discussed with dlg@, claudio@, dv@ and mlarkin@.
ok deraadt@ for the pledge part
relayd-regress: rewirte TLS tests with new keypair syntax
- TLS and non-TLS tests are handled differently now.
- Provide a CERTBASE environment for each TLS test which points to the
cert/key to test.
- The single ECDSA test has been removed, as all TLS tests are now run
separately using RSA and ECDSA certificates.
- Makefile tweaks: renamed vars and format
go ahead, bluhm@
Revert "Unlink multicast records when their interface is detached"
This reverts commit e7ea118a97a35e10ded68a7d07d4f39e3e7f57b4.
Opened a new problem instead of the old ones. Need a better fix.
bluhm@ asked for the revert which I take as implicit OK.
Reported-by: syzbot+68c8b44ea4717240232d at syzkaller.appspotmail.com
Reject non-conformant certificate subject encodings
Background:
Even though RFC 6487 section 4 is clear: "The CommonName attribute MUST
be encoded using the ASN.1 type PrintableString", some large CAs for
many years incorrectly issued certificates with UTF8String encodings
owing to a documentation bug in OpenSSL:
https://github.com/openssl/openssl/pull/23699
AfriNIC recently announced the completion of a multi-year project to
reissue all non-conformant certificates, see their final update here:
https://lists.afrinic.net/pipermail/dbwg/2026-August/000582.html
This work cleared a major hurdle for RP implementations to impose
stricter validation, in turn positively impacting the overall ecosystem
because requirement baselining and adherence to standards leads to
improved interoperability.
[14 lines not shown]