rpki-client: prepare p -> cert replacement in cert_buffer() and cert_read()
This wraps a few lines and pulls assignments out of if statements to avoid
overlong lines. The replacement will then become purely mechanical.
ok claudio
Change the high-level FUSE implementation to use the low-level API.
Currently, both APIs communicate with the kernel independently.
Even though this is a libfuse change, I've included a minor kernel
patch to remove a now unecessary check for a ENOBUFS errno. This
is not part of the FUSE protocol and is no longer needed.
I've also deleted a regression test, which checks that libfuse
functions can handle NULL as an argument. It's better that these
function segfault rather than attempt to gracefully handle bad
arguments.
There is no change to the libfuse API so shlib_version does not need a
bump.
OK claudio@
Back out the pagedaemon "oom" reserve and sleeping point
As discussed extensively. This was originally a backout
worked through by me, and then fixed and tested by deraadt@
We do not want the page daemon to sleep for other memory
resources while it should be waking sleepers and recovering
memory.
We may consider adding somthing like a reserve at a later time,
or ensure that the resources needed for swapping are always
present and never competed for, but we are backing this out
for the moment to deal with further pagedaemon bugs that this
gets in the way of solving
ok deraadt@
In uvm_pdaemon.c 1.121, 1.122, and 1.123, two things happened:
1. The shortage target inside uvmpd_scan() / uvmpd_scan_inactive() which
used to be computed using the realtime uvmexp.free value, was replaced with a
(historic prediction) using the pre-existing pagedaemon "shortage" variable.
This means the scanner will continue work even if the system recovers
memory asyncronously and has resolved the scarcity which caused the pagedaemon
to be summoned. That's a bad idea. The code should revert to observing
realtime system conditions. We don't have a diff for that yet, but the
other concern is immediate:
2. The pre-existing calculation of the "shortage" variable was changed
significally, without verifying correct behaviour.
size += shortage;
...
shortage -= bufbackoff(&constraint, size * 2);
since bufbackoff() returns how much it did, and generally succeeds at
satisfying the full request size * 2, that is effectively "shortage =
-shortage". The scan function changes still expect a positive target
[5 lines not shown]
The pagedaemon inspects the top-most sleeping pmemrange allocation for
for size and constraint, and passes this information to the inactive
scanner. The idea is that an extremely high-size and
strict-constraint allocation that fails repeatedly would percolate to
the top of the list. To ensure the scanner can inspect this
allocation's constraint via the pointer, it gets locked. Then we
release tons of memory from the buffer cache, and run the scanner to
recover free memory. At the same time, other running operations free
and allocate memory and wakeup all the sleeping pmemrange allocations,
but no, not this one, because it is locked so that the pointer won't
become invalid. When the scan is done, we may once again have meager
memory resources because all the good stuff was allocated by
asyncronous allocators, potentially creating substantial fragmentation
not compatible with the constraint. Now, the sleeping request gets
unlocked and woken to re-check it's requirements and guess what, the
constraint fails it goes back to sleep, and we need to go around
again... In practice this is a hard uvm deadlock.
Instead, copy the constraint from the request, do not lock the
allocation request and ignore the pointer.
[4 lines not shown]
ls(1): use correct buffer size for ngroup.
In numeric long format, ngroup is formatted using sizeof nuser. That's a
copy-paste bug. It's harmless only because the arrays are the same size
today; it would become a real truncation/overflow risk if they ever
diverge.
From Michal Mazurek (akfaew@), thanks!
OK kn@, tb@
rpki-client: explain why we do what we do in ta_check_pubkey()
The base64-encoded SPKI blob in the TAL should really be matched against
the corresponding part of the cert's DER. Unfortunately, libcrypto only
stores internal representations in the X509's cert_info field, so what it
hands back via the X509_* and X509_PUBKEY_* API is at best re-encoded and
therefore unsuitable for this purpose. Document this so when I will have
forgotten this the day after tomorrow, I still have a chance of not wasting
as much time for a third or fourth time next time I revisit this.
ok claudio
rpki-client: rename ta_parse() to ta_validate() and document it
ta_parse() only parses the TAL's SPKI, so it is misnamed. What it really
does is it compares the TA's SPKI to the TAL's SPKI and checks that it is
a curently valid, self-signed cert.
ok claudio
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@
