vio: recover from missed RX interrupts
It seems at least on Oracle Cloud (arm64, KVM) and on vmd, sometimes rx
interrupts get lost. As a workaround, check the virtqueues in vio_rxtick(),
which allows to recover from this situation.
Diff from renaud@
tested by mbuhl@
ok stsp@
The struct kfino_vmentry copied to userland is 80, and (depending
on architecture?) has 7 bytes of padding at the end, which is
uninitialized. Use M_ZERO.
from tgs
don't lowercase K_AUTH lookups
this diff has circulated for a while, being written and re-written by
different people. In this case, I'm taking Pietro Cerutti's version.
Avoid undefined behaviour in the community code by checking nentries to
be not 0 before memcmp, bsearch or siphash calls.
Calling these functions with a NULL pointer is UB even with a zero len.
While I did fix some code already during a review of all such possible
NULL, 0 calls I missed the bsearch one and introduced the community_equal
memcmp after that.
Reported by Synmac Oliver
OK tb@ deraadt@
Prevent buffer overflow by checking the correct counter.
An attacker on the same layer 2 network can send rogue router
advertisements, potentially crashing slaacd.
From Maurice Hieronymus (mhi AT mailbox.org), thanks!
OK deraadt
sys/octeon: cleanup all interrupts
octciu_next_irq() operates on a uint64_t pending interrupt bitmap, and
irq spans the full 0..63 range. Using 1u << irq therefore builds a 32
bit mask for a 64 bit word; once irq >= 32, the selected pending bit is
no longer cleared correctly.
The immediate consequence is loss of forward progress in the dispatcher
loop: the same interrupt can remain logically pending in the local copy
of isr, the loop can revisit it indefinitely, and the CPU can remain
trapped in interrupt handling.
OK: kettenis@, jca@, deraadt@
Properly handle the FIN flag in tcp_flush_queue.
Once a FIN packet is received all following data should simply be
discarded. Normally this is done in tcp_input but once traffic
needs reassembly the FIN handling in the reassembly queue was not
quite correct. Data directly following the FIN packet was also
reassembled and the FIN was actually lost. The check if packets
should be dropped only checked for SS_CANTRCVMORE which is only
set after tcp_flush_queue returned TH_FIN.
Reported by Xint Code
OK sashan@ deraadt@
For sysctl({CTL_KERN, KERN_TTY, KERN_TTY_INFO), only export the
t_session kernel address pointer if the caller is root.
Reported by Bruce Dang of Calif.io
ok claudio
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
