Avoid type confusion in the timestamp response parsing
A malformed v2 signing cert can lead to a type confusion, and the result
is a read from an invalid memory address or NULL, so a crash. Unlike for
OpenSSL, v1 signing certs aren't affected since miod fixed this in '14.
Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-69420.
ok jsing
Avoid type confusion in PKCS#12 parsing
A type confusion can lead to a 1-byte read at address 0x00-0xff, so a
crash.
Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-22795
ok jsing
Add NULL pointer check to PKCS12_item_decrypt_d2i()
Avoids a NULL pointer dereference triggerable by a malformed PCKS#12 file.
From Luigino Camastra via OpenSSL (CVE-2025-69421)
ok jsing
rpki-client: add cert_parse_ta()
This merges the cert_parse() + ta_parse() dance into a single specialized
function responsible for parsing a TA cert. Removes another tricky use of
cert_parse() and makes things simpler for the callers.
ok claudio job
rpki-client: add cert_parse_ca_or_brk()
This is a specialized cert parser intended for a .cer in a manifest's
fileList which therefore only accepts CA and BGPsec certificates. This
pulls a check from the parser code into the cert code where it fits a
bit better.
ok claudio job
rpki-client: factor cert_deserialize_and_parse() helper out of cert_parse()
cert_parse() is currently a bit too general: it handles TA certs, CA certs
and BGPsec router certs to accommodate the needs of file mode. The need to
perform additional checks after a call to cert_parse() makes things fragile
and led to one of the issues addressed in recent errata.
cert_deserialize_and_parse() will become a wrapper for more specialized
functions in subsequent commits. While this is not pretty either, it does
simplify things on the caller side.
ok claudio job
rpki-client: split ta_check_validity() out of ta_parse()
The check that a TA is currently valid is only done here right now. It
should probably be done in cert_check_validity_period() instead. This is
left for a later diff.
ok claudio job
fix setting DMA base addresses of iwn(4) Tx rings 17 and beyond
For Tx rings 17 and up, the driver was writing DMA base addresses
to the wrong registers. The firmware would crash when we tried to
use those rings.
This was never noticed before because those rings had never been
used by the driver until the recent introduction of support for
DSCP_EF in the wireless stack.
Use of Tx ring 17 in iwn is triggered by DSCP_EF, which the stack
is now mapping to TID 6, which the iwn code maps to queue index 16,
which addresses the 17th ring.
This issue only affected iwn 5000/6000 series devices. The earlier
devices only have 16 Tx rings and the driver respects that limit.
fatal firmware errors reported by + fix tested + ok bluhm@
Restore the comment indicating that uvmexp.wired is changed by atomics
This was changed in changes that were backed out that did not actually
make changes to uvmexp.wired. As this value is still only changed by
atomic operations, restore the comment indicating that it is.
ok kettenis@, claudio@
Modify uvmexp.paging only with atomic operations.
This was done in 1.3.1, but in conjunction with some undesirable
other changes for where this was changed and used.
This change makes the value be changed only with atomics, without
changing where or by how much it is changed, and restores the
comment in uvmexp.h to indicate it is changed by atomic ops.
ok kettenis@ claudio@
On the Qualcomm SC7280/QCS6490 SoC there is a second cell in the IOMMU
specifier that represents an SMR mask. However the "iommu-map" property
only specifies how the stream ID gets mapped. Adjust the implementation
of iommu_device_lookup_pci() based on these new insights. This means that
for PCI devices we pass an SMR mask of zero. That seems to match what
Linux does.
ok patrick@
Add a regress test that ensures our pure assembly code builds with gcc
This requires egcc to be installed, if not we'll just skip the test.
Discussed with tb@
Make SHA aarch64 assembly build with gcc.
gcc is extremely fussy about register naming and insists on q and s naming
for the ARM CE SHA instructions, even though they're referring to the same
register (while LLVM just figures it out). Work around this by mapping
registers to their required variant at usage and defining a handful of
mappings between v registers and alternate names/views.
This is still somewhat ugly, but seems to be one of the cleaner options
that will allow portable to enable SHA assembly on platforms that use gcc.
ok kenjiro@ tb@
Tidy instruction separators in SHA assembly.
Remove unnecessary separators and add a few to macros that call other
macros (instead of expecting them to exist).
