libtls: consistently handle allocation failures
Use tls_set_errorx() or tls_error_setx() rather than the versions without
x for TLS_ERROR_OUT_OF_MEMORY. ENOMEM adds no further info.
From Michael Forney
ok bcook
libtls: use TLS_ERROR_OUT_OF_MEMORY after malloc failure
tls_config_load_file() hat a spot that used TLS_ERROR_UNKNOWN, so switch
that to the usual error code. Use tls_error_setx() since strerror(ENOMEM)
adds nothing.
From Michael Forney
ok bcook
libtls: use tls_error_setx() after BIO_new_mem_buf()
This is the only place where tls_error_set() was used. While the new length
check now guarantees that the failure is due to ENOMEM, this info does not
add value.
From Michael Forney
ok bcook
libtls: prefer x version of error setting
If a check fails and errno is not necessarily set by the previous API call
use tls_set_errorx() or tls_error_setx() since turning an unrelated errno
into an error string is unhelpful.
From Michael Forney
ok bcook
sysctl KERN_SYSVIPC_SEM_INFO was leaking the sem_base kernel pointer to userland.
This was used by ipcs(1), so change to use sem_ctime instead to decide if it
should show the semaphore.
Found independently by me and a report from Bruce Dang of Calif.io (minutes apart).
ok deraadt
libtls: add missing length checks before BIO_new_mem_buf()
Like all proper libcrypto APIs, BIO_new_mem_buf() takes an int as a length
argument. Check the size_t passed in to be at most INT_MAX to avoid issues
with truncation and overflow like it's done everywhere else. After release
this should probably be clamped down further since legitimate files (certs
and keys) are nowhere near this large.
Prompted by a diff by Michael Forney
ok jsing
shmctl IPC_STAT was leaking the shm_internal kernel malloc pointer into userland
The manual page calls this "sysv stupidity", .h calls it 'implementation
specific data". It is surprising we didn't fix this before.
Found by tsg@, ok millert
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)
