Furthermore there are no configuration options for "key negotation",
so we believe everyone knows to run this on a dedicated wire or on L2 inside
some sort of encryption tunnel (it is the natural way to do it in anycase).
Books do mention this detail, because books enjoy being more wordy.
But the AI's can't figure it out, so put in some words to stop future
AI's from sending us slop.
packet. It provides absolutely no security benefits, keep reading to
find out.
According to dlg, during early development this field was hopefully
going to be a hash related to the ruleset for optimizing state
match. That approach was abandoned (I guess because ruleset drift
between firewalls happens too often during normal practice). As is
usual in protocol development, at least 6 people were already using
pfsync in production, so for compatibility the field was not
removed... and forgotten. On send, it was left as zero, due to
the full-header zero initialization code.
So there is no useful checksum or hash stored in this field called
'pfcksum[PF_MD5_DIGEST_LENGTH]'. Actually there isn't a single line
of code in the entire tree which writes to this array. Besides the
field definition in the structure, there is 1 comment elsewhere
mentioning the field. So no code at all. I said no code, which is
why there is no code checking it on receive, not even checking if it
is still zero.
An (obviously) AI-assisted report (which I do not intend to share)
arrived which tells us FOR SURE that field is being computed on send,
but not checked on arrival which is a security risk!!!!
It goes into extensive detail saying where various parts of this subsystem
are and how it all fits together but apparently it is all an elaborate
fiction built upon two words 'pfcksum' and 'PF_MD5_DIGEST_LENGTH'. No
words about security principles are found anywhere in the code or
in the manual page because everyone uses this on a dedicated wire
between firewall boxes.
The human who caused an AI to generate that report did not "peer-review"
the result (hint: the command is grep) before sending it to us, and has
caused David to pull a muscle when his eyes rolled back too far.
To avoid future confusion by AI+humans, rename the field from
pfcksum[PF_MD5_DIGEST_LENGTH] to spare[16].
ok dlg
any vnode. A block of #if 0 code suggests this might be different.
That can be deleted. This also shows one word "other" in the manual
page is misleading.
question asked by Stuart Thomas
ok beck
and damage it strangely. Such a binary cannot actually run, but we should
avoid the internal pinsyscall table damage, and fail the execve with EINVAL.
reported by Stuart Thomas
ok guenther
vmm(4) handles the %dr6 debug register on VMX on its own. It is not
part of the VMCB. The AMD and Intel SDMs mention that a 'MOV DRn'
instruction traps with #GP when any of the upper 32 bits of %dr6/%dr7
is 1. Userland can set arbitrary values in that register, forcing an
Intel machine to crash. An initial bogus %dr7 fails to launch the VM
on both platforms.
Reject such debug register values an all platforms.
ok mlarkin@
Reported-by: syzbot+f386e2f64711877025a6@syzkaller.appspotmail.com
repo_abort() called by repo_check_timeout() will add messages to
be sent out.
This brings back rev 1.263 which was accidentially reverted by rev 1.293
OK tb@
sleeping pmemrange allocations with multi-page alignment requirements
which can't be satisfied by the simplistic freeing of (solo) pages
which the pagedaemon performs. As we near starvation, fragmentation
is the main problem. Our free list could be large enough that the
pagedaemon sees no reason to do more work, but also too fragmented to
satisfy a pending allocation request with complex requirements
(imagine asking for 512K of physically linear memory which is DMA
reachable). When the requirement isn't satisfied, the pagedaemon is
told to try again, but again doesn't mean harder because it has no
mechanism to try harder. It's tracking variables do not show the
fragmentation problem. It spins a lot. Often this becomes a
deadlock.
Time to change strategy: Overshoot creation of (both) inactive and
free pages each time through the loop. After inspecting existing
variables, we generate minumum 128 inactive pages (which may be
dynamically drawn down asyncronously by accesses), and then try to
convert minumum 128 inactives into free pages (different pages
get freed different ways, including via swapcluster which has been
improved in previous uvm_swap.c commit to absorb more pressure and
indicate when it is full).
As we mow through the freelist, this will eventually create some
(physical address space) defragmention and satisfy these complex
requirements. Maybe not on the first round, but it will keep trying.
Before this change, it was not trying at all.
ok kettenis kirill beck
Since this is runs inside the pagedaemon that is unworkable. We'd like to
encrypt the pages inplace for IO, but there are architectures not ready for
a high-mem page to be written to a dma-restricted device (work in progress).
So for now we need to bounce through dma-reachable memory buffer. A previous
attempt had 1 extra bounce buffer, but then slept on allocation inside the
pagedaemon context which is also unworkable. This version contains 32
pre-allocated swapclusters (64K each), and through a counter signals to the
pagedaemon when it should stop trying to create memory. 32 swap clusters
is comfortably more than the minimum we expect the pagedaemon frantically
generate. This crummy solution is good enough until we the dma reach problem
is solved (soon)
ok kettenis kirill (who looked into other solutions) beck
i8254 clock either when coming out of S3 suspend. So move the code
that checks whether the RTC alarm went off and clears it all the way to
the end of acpi_cpu_resume. This fixes a lockup seen on the x220.
Figured out by mlarkin@ who write the initial diff; I just tweaked it.
ok mlarkin@, deraadt@
bufbackoff() operates in pages, but size at this call site was a byte
count; the old loop therefore asked for far too much backoff and
compared reclaimed pages against bytes.
On a low memory machine that made the NOWAIT retry path much less likely
to succeed, so the code dropped into the WAITOK allocation below and
slept.
Using atop() puts the units back in line; backoff can now satisfy the
intended request, and the subsequent NOWAIT retry again has a realistic
chance of success. The WAITOK path remains possible, but it should be
reached less often.
OK deraadt@, beck@
to ensure that the response includes all needed data.
Right now only the presence of a Location header is checked if a HTTP
redirect was returned (e.g. a 301 status).
Different fix for a report from Daniel Anderson
OK tb@
I got an empty trace. It was reading garbage as the 1st return
address and might have accidentally taken the "if (lr & 3) break;".
By using __builtin_return_address(0) and pointing to the correct
frame, I get a trace where #0 is the function calling
stacktrace_save().
i messed up when we added support for names on these things. the
id and names are each supposed to be unique, which is checked by
putting the one limiter into an rb tree based on their id and another
based on their name. unfortunately i used the same RBT_ENTRY fields
for both trees, which meant using both trees on the same limiter
corrupted the topology, which goes badly when you want to use
multiple limiters.
found by, tested, and ok dgl@ (who is not me, this is not a typo)
ok jmatthew@
might find in the current ports tree. kde3/kde4 and their tags are
long gone.
Leave them in place for the historical section describing what
tags are used for in dpb/DPB_PROPERTIES
ok phessler
last component of the path is an existing directory and O_DIRECTORY
is not specified.
This is required by recent versions of POSIX. We previously did
not return an error.
Flagged by Sortix os-test.
committing on behalf of daniel@, partly based on FreeBSD changes
ok guenther@ jsg@ deraadt@
RFC5321 §4.1.4 states that an EHLO command MAY be issued by a client
later in the session and, if it's acceptable, it MUST clear all buffers
and reset the state exactly as if a RSET command was issued.
discussed with / okay martijn@
Before this change:
If no file or directory matching the last component of a path existed.
A regular file was created, an error was returned and errno set to ENOTDIR.
If a regular file matching the last component of a path existed,
an error was returned and errno set to ENOTDIR.
If a directory matching the last component of a path existed,
it was opened without error.
One possible reading of POSIX is that O_CREAT | O_DIRECTORY is a valid way
to get a file descriptor for an existing directory. In practice it isn't
used and the combination of O_CREAT and O_DIRECTORY has returned an error
on NetBSD since 2010 and Linux since 2023.
ok deraadt@ daniel@
pull the hardware differences out into a per-variant structure containing
the different parameters we have to program.
tested on 3528 (radxa e20c), 3568 (nanopi r5s), 3588 (nanopi r6c)
feedback from kettenis@
ok kettenis@ dlg@
Adding -DEBUGGING in CONFIGURE_ARGS activates debug code,
-DEBUGGING=-g passes -g in CFLAGS (only -g is supported),
and -DEBUGGING=both does... both. This is a bit confusing.
IMO DEBUG=-g should only add -g and disable executable stripping, but
not change the code that is built. So use -Doptimize which lets us pass
arbitrary compiler flags (eg -g3), just like DEBUG does in our system
Makefiles.
Hints and ok afresh1@
This converts rsa_cms_decrypt() to use X509_ALGOR_get0() and fixes a
NULL deref when a parameter is (invalidly) omitted similar to the fix
in ec/ec_ameth.c r1.66 from a couple years back. There is currently
an XXX annotating a hairy leak due to trying to be smart and stealing
the parameters from the oaep object. Instead, just make a copy of the
label string and free it in the exit path.
The diff adds an error for labellen == 0 since that is an invalid
encoding of pSpecifiedEmpty (see RFC 8017) -- per the DER the default
must be omitted. This way we avoid a malloc(0) implementation-defined
behavior.
This minor issue was assigned CVE-2026-28390 by OpenSSL and was reported
by too many to list. The fix is my own. It is similar to OpenSSL's fix
only because I rewiewed theirs and suggested an improvement or two.
This is the last of the "security fixes" in today's OpenSSL release that
"affect" LibreSSL. All the other bugs were already fixed a few years back
or we didn't have the code/bugs in the first place.
ok beck jsing
Instead of reaching deep inside the OCSP_BASICRESP and ignoring its
semantics and then try to untangle things in ocsp_find_signer_sk(),
pass the OCSP_BASICRESP and use OCSP_resp_get0_id() which has the
logic built in. Avoids a crash if you call OCSP_basic_verify() after
OCSP_BASICRESP_new() without OCSP_basic_sign(). This cannot happen on
a deserialized OCSP object.
Prompted by a report by Kamil Frankowicz, Jan Kaminski, Bartosz Michalowski.
ok jsing
Prompted by the "fix" fighting symptoms of misdesign in Delta CRL processing
rather than addressing the root cause. Probably the best fix is to remove
support for Indirect CRLs and Delta CRLs outright.
ok jsing
A malformed Delta CRL could cause a crash. Funnily enough the deserializer
recognizes this and marks such a CRL as invalid, but nothing ever checks
the EXFLAG_INVALID for CRLs. For certificates this would usually result in
verification failure due to x509v3_cache_extensions() failing.
This is only reachable if the X509_V_FLAG_USE_DELTAS is used, which only
a handful of ports do, plus openssl(1) does if you use the undocumented
-use_deltas flag.
Reported by Igor Morgenstern to OpenSSL who then sat on this since Jan 8
and assigned CVE-2026-28388.
ok jsing
OpenSSL called these NID_sbgp_ipAddrBlock and NID_sbgp_autonomousSysNum
from which rpki-client derived its own fantasy names. Use the official
names in RFC 3779 instead: id-pe-ipAddrBlocks and id-pe-autonomousSysIds.
ipaddrblk is ugly and can be expanded in the API. Use addrs for the
variable to avoid overlong lines. There's precedent in the constraints
code.
The doubled s in assysnum makes no sense and since autonomoussysids is
long and unreadable, I used asids in the API.
ok claudio