Build date: 1776290403 - Wed Apr 15 22:00:03 UTC 2026 Build cvs date: 1776287773 - Wed Apr 15 21:16:13 UTC 2026 Build id: 2026-04-16.1 Build tags: amd64-regress ports sysupgrade Applied the following diff(s): /home/anton/tmp/robsd/src-sys-em.diff /home/anton/tmp/robsd/src-sys-ramdisk-diet.diff /home/anton/tmp/robsd/src-sys-uhidev-sispm.diff /home/anton/tmp/robsd/src-sysupgrade.diff P lib/libc/time/ctime.3 P regress/lib/libtls/keypair/keypairtest.c P sbin/dhcpleased/dhcpleased.c P sbin/dhcpleased/dhcpleased.h P sbin/dhcpleased/engine.c P sbin/dhcpleased/frontend.c P sys/arch/riscv64/dev/smtcomphy.c P sys/arch/riscv64/riscv64/pmap.c P sys/dev/pci/ixgbe.h P sys/dev/pci/ixgbe_type.h P sys/dev/pci/drm/i915/gt/uc/intel_guc_submission.c M sys/dev/usb/uhidev.c P sys/kern/kern_fork.c P sys/kern/kern_sysctl.c M usr.sbin/bgpd/session.c commit RGzRbxBKC4fTB4jp Author: kettenis Date: 2026/04/15 21:16:13 Calibrate the PHY if the firmware didn't do so already. ok jsing@ (who came up with a very similar diff) sys/arch/riscv64/dev/smtcomphy.c commit geMWFxMtRcI3I3H6 Author: kettenis Date: 2026/04/15 21:15:08 The riscv64 pmap implementation copies the kernel l1 page table entries into all other pmaps to allow access to KVA when running in kernel mode. Unfortunately when pmap_growkernel() creates new kernel l1 page table entries, existing pmaps are not updated. This causes unexpected kernel page faults when KVAs that depend on those new kernel l1 page table entries are used. Fix this by fully populating the kernel l1 page tables in pmap_bootstrap(). ok mlarkin@, jca@ sys/arch/riscv64/riscv64/pmap.c commit vWnz7Cla8TD5JiL8 Author: tb Date: 2026/04/15 20:13:07 keypairtest: zero out tls_error before running tests Otherwise tls_error_clear() (called e.g. via tls_error_vset()) will free the bad error->msg pointer. From Michael Forney regress/lib/libtls/keypair/keypairtest.c commit utmGg9zcRLLCTS8S Author: deraadt Date: 2026/04/15 19:29:02 sysctl skips processes with pr->ps_pgrp == NULL. comment said this was dying processes. actually it is also brand new processes now. sys/kern/kern_sysctl.c commit obB9sbDVQjmLVDa2 Author: bluhm Date: 2026/04/15 19:04:31 During early stages of fork in process_new(), since the ps_pgrp field is in the process copy region the child gets this pointer. Before fork1() completes the process creation, it is possible for other processes to change the pgrp in an attacker controlled way, such that the pointer becomes stagnant. A very complicated AI-generated attack chaining many methods (which a experienced human could generate given sufficent time) suceeds at racing this stagnant pgrp object in the pool cache and can do things it should not. We need to start the children without a pgrp (ie. NULL), and update the pgrp pointer late. from deraadt@; Found by Nicholas Carlini at Anthropic this is errata/7.7/037_pgrp.patch.sig sys/kern/kern_fork.c commit F5EyyRHQU4ZDZ8zV Author: bluhm Date: 2026/04/15 19:04:12 During early stages of fork in process_new(), since the ps_pgrp field is in the process copy region the child gets this pointer. Before fork1() completes the process creation, it is possible for other processes to change the pgrp in an attacker controlled way, such that the pointer becomes stagnant. A very complicated AI-generated attack chaining many methods (which a experienced human could generate given sufficent time) suceeds at racing this stagnant pgrp object in the pool cache and can do things it should not. We need to start the children without a pgrp (ie. NULL), and update the pgrp pointer late. from deraadt@; Found by Nicholas Carlini at Anthropic this is errata/7.8/031_pgrp.patch.sig sys/kern/kern_fork.c commit p8OiI4rr9MLm3wHv Author: deraadt Date: 2026/04/15 18:55:54 During early stages of fork in process_new(), since the ps_pgrp field is in the process copy region the child gets this pointer. Before fork1() completes the process creation, it is possible for other processes to change the pgrp in an attacker controlled way, such that the pointer becomes stagnant. A very complicated AI-generated attack chaining many methods (which a experienced human could generate given sufficent time) suceeds at racing this stagnant pgrp object in the pool cache and can do things it should not. We need to start the children without a pgrp (ie. NULL), and update the pgrp pointer late. Found by Nicholas Carlini at Anthropic this is security errata 7.7/037_pgrp.patch.sig and 7.8/031_pgrp.patch.sig sys/kern/kern_fork.c commit YgymiD6AJWVBUxol Author: stsp Date: 2026/04/15 17:30:50 Make the ix(4) driver compile when DBG is set to 1 in ixgbe.h. ok claudio@ deraadt@ sys/dev/pci/ixgbe.h sys/dev/pci/ixgbe_type.h commit BEJSYZ1lj54Mh2YX Author: florian Date: 2026/04/15 16:50:32 Do not pass pointers over privilege boundaries. These might give hints about the address layout of the privileged process. Instead, don't be lazy and pass an imsg struct that only contains data and no pointers. Issue raised by Systopia Team. Input & OK claudio@ Prodding & "I love it" deraadt@ sbin/dhcpleased/dhcpleased.c sbin/dhcpleased/dhcpleased.h sbin/dhcpleased/engine.c sbin/dhcpleased/frontend.c commit mM9nxrQvMJHsKbkR Author: jsg Date: 2026/04/15 03:00:20 init GuC TLB invalidation xarray with XA_FLAGS_LOCK_IRQ The xarray is used from interrupt context: xa_lock_irqsave wait_wake_outstanding_tlb_g2h intel_guc_tlb_invalidation_done ct_process_request ct_handle_event ct_handle_hxg ct_handle_msg ct_receive ct_try_receive_message intel_guc_ct_event_handler intel_guc_to_host_event_handler guc_irq_handler gen11_other_irq_handler gen11_gt_identity_handler gen11_gt_bank_handler gen11_gt_irq_handler dg1_irq_handler avoids a 'locking against myself' panic seen on a non-mp kernel with DRMDEBUG and CONFIG_DRM_I915_DEBUG_GUC sys/dev/pci/drm/i915/gt/uc/intel_guc_submission.c commit APPf9fHsnwnbFQa7 Author: job Date: 2026/04/15 00:20:28 Provide an example how to disambiguate mktime() return values OK beck@ lib/libc/time/ctime.3