The maximum depth is not expected to include the leaf certificate - restore
the decrement prior to checking, which means the previous behaviour is
retained for the callback depth and the maximum depth. Reduce the maximum
depth by one in order to avoid the overwrite that could previously occur.
Thanks to anton@ for flagging the rust-openssl failure in regress.
ok tb@
add a call to drm_fb_helper_restore_fbdev_mode_unlocked()
to amdgpu_enter_ddb() otherwise ddb output can't be seen
not required on inteldrm or radeondrm
This reimplements simpler versions of logging functions needed for
linking the qcow and raw disk image code from vmd.
Also cleans up the Makefile a bit, removing atomicio.c which is
unused.
ok mlarkin@
E-core (Atom) without L3 cache. These cpus are Lethargic, and it sucks
when processes migrate to them.
This introduces sysctl hw.blockcpu= which takes a sequence of 4 letters.
S (for SMT), P (regular performance cpu), E (efficient cpu) generally
80% to 50% as fast), and L (lethargic cpu) which are even slower.
By setting this, you can select cpus to kick out of the scheduler. The
default is SL.
The hw.smt sysctl remains for now but we will eventually delete it.
hw.smt changes and follows hw.blockcpu=S.
ok kettenis mlarkin
In x509_verify_build_chains(), ensure that we check the current depth
against max_depth prior to turning it into a legacy-style depth index.
Additionally, add a guard to x509_verify_chain_append() so that we avoid
exceeding the maximum certs per chain, even if we fail to handle this
correctly elsewhere. Also prevent the legacy callback from being able
to override the maximum verification depth.
The current off-by-one allows for a 4 byte overwrite to occur on heap
allocated memory - this will likely trigger a crash on OpenBSD (but may
go unnoticed elsewhere). This is only reachable if a TLS client is talking
to a malicious server or if a TLS server has client certificate
verification enabled - in both cases the verification depth also needs to
be set to the maximum allowed value of 32.
It is worth noting that many TLS clients/servers set the maximum
verification depth to a value that is much less than the default. A libtls
client or server uses a default depth of 6 and is not impacted in this
configuration.
Thanks to Calif.io in collaboration with Claude and Anthropic Research,
for reporting the issue.
ok tb@
ida is accessed from both process and interrupt contexts.
The interrupt context use occurs when a fence is hardware signaled:
dma_fence_signal -> amdgpu_pasid_free_cb -> ida_free -> idr_remove
linux currently uses an xarray with XA_FLAGS_LOCK_IRQ for ida, which
blocks interrupts when locked
This change was prompted by protection faults such as:
idr_tree_SPLAY+0x58
idr_alloc+0xb1
amdgpu_pasid_alloc+0x5d
amdgpu_driver_open_kms+0xac
drm_file_alloc+0x245
drmopen+0x12c
seen with 6.12 and 6.18 drm
volker@ could more consistently reproduce this on a system with a
Navi 31 (7900 XTX).
Lots of testing from volker@ and feedback from kettenis@
Support of 160Mhz window brings a regression for drivers which do not
supprot 160MHz window which leads to the wrong channel center.
It was tested on iwx with and without 160Mhz window support in the code
agaisnt 2.4Ghz network with 20Mhz and 40Mhz, and 5Ghz with 40Mhz, 60Mhz,
80Mhz and 160Mhz window.
Reported as iwm issue by martijn@
OK: stsp@
so that history shrinks, data->oy can exceed screen_hsize causing an
unsigned integer underflow in the py computation. Clamp data->oy in
window_copy_resize and window_copy_cmd_refresh_from_pane before the
subtraction. From futpib at gmail dot com in GitHub issue 4958.
ProxyJump/-J on the commandline as we do for destination user/host
names.
Specifically, they are no longer allowed to contain most characters
that have special meaning for common shells. Special characters are
still allowed in ProxyJump commands that are specified in the config
files.
This _reduces_ the chance that shell characters from a hostile -J
option from ending up in a shell execution context.
Don't pass untrusted stuff to the ssh commandline, it's not intended
to be a security boundary. We try to make it safe where we can, but
we can't make guarantees, because we can't know the parsing rules
and special characters for all the shells in the world, nor can we
know what the user does with this data in their ssh_config wrt
percent expansion, LocalCommand, match exec, etc.
While I'm in there, make ProxyJump and ProxyCommand first-match-wins
between each other.
reported by rabbit; ok dtucker@
Add the three RSASSA-PSS SignatureScheme 0x080b, 0x080a, 0x0809 in the
appropriate spots in (components of) the ClientHello and adjust various
length octets by adding 6.
Announce the signature schemes for RSASSA-PSS with pubkey OID RSASSA-PSS
between RSASSA-PSS with pubkey OID rsaEncryption and RSASSA-PKCS1-v1_5.
This is the last step in the everlasting saga for making these signature
schemes and certificates with RSASSA-PSS OID work. Fortunately, these are
rarely used since they are extremely complex and inefficient also due to
the large size of the parameters. This addresses bug reports by Steffen
Ullrich and Tom Lane.
Tested by bluhm.
ok djm jsing kenjiro
This fixes a long-standing logic error that hasn't been noticed because
we never announced the rsa_pss_pss_sha{256,384,512} SignatureScheme. The
EVP_PKEY_id() of a RSA-PSS pubkey is EVP_PKEY_RSA_PSS, not EVP_PKEY_RSA.
Thanks to beck for helping me figure out how to fix this correctly. It
drove me nuts for a very long time. Problem also noticed by Tom Lane
due to some PostgreSQL regress failures.
ok djm jsing kenjiro
Multicast timers are protected by poper locks. The shortcut that
avoids locking when no timers are scheduled, does not need an
additional membar.
OK mvs@
Editing files on tmpfs uses nanotime() to update mtime, and touch uses
utimensat(UTIME_NOW) which uses getnanotime() which is cached and which
can be smaller.
So, sed ... A && touch B leads to mtime(A) > mtime(B) which isn't excted.
"Yep" deraadt@
This looks like a NULL dereference that should crash, but for some reason
it doesn't, even with -O0 with all compilers i tried. At the very least it
may result in compilers deducing that key_768 != NULL and lead to incorrect
optimizations.
ok claudio jsing kenjiro miod
The users of this code are single threaded today. The locks also
don't look to fully protect key state in qcow images. If/when virtio
block emulation ends up with multiple virtqueues, this will need
to be revisited.
ok mlarkin@, hshoexer@
