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@
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
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
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
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
Update to 3.4.2, a stable bugfix release. Includes:
* Fixed potential buffer overflow in tRNS handling
* Fixed out of bounds read in XCF image loader (CVE-2026-35444)
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@
drop exim from ports, this has been proposed various times over the last
couple of years but nobody actually got round to it yet, and it seems like
a good point in the release cycle to say bye, the port installs it suid
root and it has had quite a few too many security issues to be comfortable
with this.
ok job, tb, renaud (maintainer)
