HBSD: Document rejection of AI/LLM/etc generated works
HardenedBSD is disinterested in navigating potential copyright issues.
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
git-arc: Handle -h on subcommands and align usage with the man page
git-sh-setup treats -h as help against an empty USAGE, so
"git arc create -h" prints "usage: git arc". Handle -h before
sourcing it so every subcommand prints the real synopsis.
The create, stage, and update synopses showed optional commit-refs
while git-arc(1) and the code require them. Advertise -p parent on
create; the option was already implemented and documented.
Sort create sub-command option-arguments alphabetically in three
places: (1) synopsis from tool, (2) man-page synopsis, and (3)
man-page description.
Check for jq(1) / arc after checking for usage so -h always works.
While here, fix missing "local o" in gitarc__stage().
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D59129
pf: Re-optimize state key handling
pf states may be looked up using one of two keys: the stack key or the
wire key. For states involving address translation, these will be
distinct; the stack key describes the addresses seen by the local
network stack, and the wire key has the translated addresses.
Historically, pf would avoid allocating separate keys if both are
identical. This changed in commit fcdb520c1b4e ("pf: nat64") to always
allocate separate state key structures. Incidentally, OpenBSD seems to
maintain the optimization, but also has an explicit reference count
embedded in state keys.
The change breaks another optimization: pf_state_key_attach() still uses
state key pointer equality to check whether the stack and wire keys are
equal, so those checks are always false after the aforementioned commit.
Thus we never skip the second key lookup, even when that's possible
(i.e., no address translation is involved).
[13 lines not shown]
socket: Restore handling of IPPROTO_DIVERT
Python scripts which use divert sockets no longer work after commit
e967a2a03677; even if one patches socket() calls, getaddrlen() doesn't
work on divert sockets, needed to use recvfrom().
Restore compatibility when COMPAT_FREEBSD15 is defined.
Reviewed by: kib
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D59018
openssh: Fix shosts.equiv path in manual pages
Change the path for the shosts.equiv file to consistently reflect
/etc/ssh/shosts.equiv across all manual pages.
This change stems from 35d4ccfb5576 ("Document FreeBSD defaults and
paths.")
Reviewed by: bcr, emaste
Differential Revision: https://reviews.freebsd.org/D52203
posixshm: Fix a TOCTOU race in the FIOSSHMLPGCNF handler
The check for whether shm_lp_psind was assigned was unlocked. This race
can be exploited to create an object with psind==2 but with only
pagesizes[1] worth of pages populated. This in turn can be used to
escalate privileges.
Fix this by acquiring the rangelock earlier. In shm_mmap_large(),
assert that we hold the rangelock. In shm_write(), annotate an unlocked
load of shm_lp_psind.
Approved by: so
Security: FreeBSD-SA-26:63.posixshm
Security: CVE-2026-58094
Reported by: tsune of GMO Cybersecurity by Ierae, Inc. working with TrendAI Zero Day Initiative
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59104
tty: Revalidate after dropping the tty lock in ioctl handlers
The TIOCSCTTY ioctl handler drops the tty lock in order to acquire the
proctree relock. After relocking the tty, it did not revalidate the
tty state, and it could end up linking a doomed tty to the calling
process' session. This race can be exploited to escalate privileges.
TIOCSPGRP has a similar race, fix that too.
Approved by: so
Security: FreeBSD-SA-26:62.tty
Security: CVE-2026-58093
Reported by: tsune of GMO Cybersecurity by Ierae, Inc. working with TrendAI Zero Day Initiative
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59126
hwpmc: Fix the execve handler
When a process execve()s, pmc_process_exec() is supposed to evaluate
whether the new image is setuid/setgid and if so, whether to detach
PMCs. This was handled by pmc_can_attach(), which is effectively an
open-coded copy of cr_xids_subset().
Unfortunately, the test of the result of this function was inverted,
with the result that we'd detach PMCs only if the predicate said it was
okay to do so. It appears the bug has always been there; it seems the
intent was to return 0 on "success", i.e., it is okay to attach the
PMCs, much like p_candebug(). Commits 1c3c698ba4c4 and 1c40b15971f0
obscured this a bit.
I think this check is trying to be too clever. Let's make it simpler:
simply do not attach PMCs unless the owner is privileged. This is how,
e.g., ktrace works. I do not think it's worth trying to be more
sophisticated than this unless we can generalize the policy in a way
that's applicable to other subsystems.
[11 lines not shown]
openssl: Fix multiple vulnerabilities
This is a rollup commit from upstream to fix:
Handle signature_algorithms_cert extension in key-only context
Avoid double free of qrx in port_default_packet_handler()
Avoid full read buffer allocation when buffering DTLS next-epoch records
ssl/record/methods/dtls_meth.c: lower the unprocessed_rcds queue limit
ssl/record: remove dead DTLS processed_rcds record queue
Fix heap buffer overflow (8-byte OOB write) in AES-WRAP-PAD unwrap
CMP unexpected sender DN used as format string in ERR_raise_data()
Add test for CVE-2026-63073
Add a test for restricting growth in cmp cert cache
Fix unbounded cert cache growth in cmp
Don't store ACK-only frames in TX history for QUIC.
Add test for CVE-2026-63076
Fix Remote NULL deref in ossl_cmp_calc_protection() via crafted protectionAlg
Approved by: so
Obtained from: OpenSSL
[8 lines not shown]
cred: Fix group_is_primary()
This helper wasn't updated in commit be1f7435ef21, so in reality it was
testing whether "gid" is the first supplemental group. If a user
doesn't belong to a supplementary group, then it's testing an
uninitialized slot; since ucreds are allocated with M_ZERO, this
typically means that we're testing gid == 0.
group_is_primary() has exactly one use, in mac_do. There, it's used to
determine whether to keep the caller's current primary groups. This
means that a rule such as gid=0>uid=0 will permit any credential with no
supplementary groups.
I believe this is mostly exploitable by daemons which have explicitly
dropped privileges and called setgroups(0, NULL); logged in users will
have a non-empty supplementary group list by virtue of having gone
through initgroups(3).
Fix group_is_primary(), and add a regression test.
[9 lines not shown]
dsp: Fix a potential use-after-free in dsp_oss_syncstart()
This function has a loop where it attempts to lock all channels in a
group. If doing so would block, it releases all locks, sleeps for a
bit, and tries again. However, once the syncgroup lock is dropped,
nothing prevents the syncgroup structure from being freed.
Fix the inner loop: after waking up, break out of it unconditionally and
start everything again. I think the old code was also buggy and not
well-exercised: after waking up we'd continue to try and continue
locking channels. Then we'd try again from the beginning and fail to
lock the channels we had already locked.
Approved by: so
Security: FreeBSD-SA-26:58.sound
Security: CVE-2026-58091
Reported by: Hazley Samsudin of GovTech CSG
Reviewed by: christos
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58912
tty: Revalidate after dropping the tty lock in ioctl handlers
The TIOCSCTTY ioctl handler drops the tty lock in order to acquire the
proctree relock. After relocking the tty, it did not revalidate the
tty state, and it could end up linking a doomed tty to the calling
process' session. This race can be exploited to escalate privileges.
TIOCSPGRP has a similar race, fix that too.
Approved by: so
Security: FreeBSD-SA-26:62.tty
Security: CVE-2026-58093
Reported by: tsune of GMO Cybersecurity by Ierae, Inc. working with TrendAI Zero Day Initiative
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59126
dsp: Fix a potential use-after-free in dsp_oss_syncstart()
This function has a loop where it attempts to lock all channels in a
group. If doing so would block, it releases all locks, sleeps for a
bit, and tries again. However, once the syncgroup lock is dropped,
nothing prevents the syncgroup structure from being freed.
Fix the inner loop: after waking up, break out of it unconditionally and
start everything again. I think the old code was also buggy and not
well-exercised: after waking up we'd continue to try and continue
locking channels. Then we'd try again from the beginning and fail to
lock the channels we had already locked.
Approved by: so
Security: FreeBSD-SA-26:58.sound
Security: CVE-2026-58091
Reported by: Hazley Samsudin of GovTech CSG
Reviewed by: christos
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58912
posixshm: Fix a TOCTOU race in the FIOSSHMLPGCNF handler
The check for whether shm_lp_psind was assigned was unlocked. This race
can be exploited to create an object with psind==2 but with only
pagesizes[1] worth of pages populated. This in turn can be used to
escalate privileges.
Fix this by acquiring the rangelock earlier. In shm_mmap_large(),
assert that we hold the rangelock. In shm_write(), annotate an unlocked
load of shm_lp_psind.
Approved by: so
Security: FreeBSD-SA-26:63.posixshm
Security: CVE-2026-58094
Reported by: tsune of GMO Cybersecurity by Ierae, Inc. working with TrendAI Zero Day Initiative
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59104
cred: Fix group_is_primary()
This helper wasn't updated in commit be1f7435ef21, so in reality it was
testing whether "gid" is the first supplemental group. If a user
doesn't belong to a supplementary group, then it's testing an
uninitialized slot; since ucreds are allocated with M_ZERO, this
typically means that we're testing gid == 0.
group_is_primary() has exactly one use, in mac_do. There, it's used to
determine whether the requested primary GID can be used in a setcred(2)
call when the ruleset does not explicitly specify a target primary GID.
I believe this is mostly exploitable by daemons which have explicitly
dropped privileges and called setgroups(0, NULL); logged in users will
have a non-empty supplementary group list by virtue of having gone
through initgroups(3).
Fix group_is_primary(), and add a regression test.
[8 lines not shown]
openssl: Fix multiple vulnerabilities
This is a rollup commit from upstream to fix:
Handle signature_algorithms_cert extension in key-only context
Avoid double free of qrx in port_default_packet_handler()
Avoid full read buffer allocation when buffering DTLS next-epoch records
ssl/record/methods/dtls_meth.c: lower the unprocessed_rcds queue limit
ssl/record: remove dead DTLS processed_rcds record queue
Fix heap buffer overflow (8-byte OOB write) in AES-WRAP-PAD unwrap
CMP unexpected sender DN used as format string in ERR_raise_data()
Add test for CVE-2026-63073
Add a test for restricting growth in cmp cert cache
Fix unbounded cert cache growth in cmp
Don't store ACK-only frames in TX history for QUIC.
Add test for CVE-2026-63076
Fix Remote NULL deref in ossl_cmp_calc_protection() via crafted protectionAlg
Approved by: so
Obtained from: OpenSSL
[8 lines not shown]
hwpmc: Fix the execve handler
When a process execve()s, pmc_process_exec() is supposed to evaluate
whether the new image is setuid/setgid and if so, whether to detach
PMCs. This was handled by pmc_can_attach(), which is effectively an
open-coded copy of cr_xids_subset().
Unfortunately, the test of the result of this function was inverted,
with the result that we'd detach PMCs only if the predicate said it was
okay to do so. It appears the bug has always been there; it seems the
intent was to return 0 on "success", i.e., it is okay to attach the
PMCs, much like p_candebug(). Commits 1c3c698ba4c4 and 1c40b15971f0
obscured this a bit.
I think this check is trying to be too clever. Let's make it simpler:
simply do not attach PMCs unless the owner is privileged. This is how,
e.g., ktrace works. I do not think it's worth trying to be more
sophisticated than this unless we can generalize the policy in a way
that's applicable to other subsystems.
[11 lines not shown]
arm: Quote diagnostic message
The C standard does not require diagnostic messages to be quoted, but
some tools get confused by unbalanced quotes such as the apostrophe in
“don't”. Wrap this message in double quotes to resolve the confusion.
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
arm64: Fix the indentation of ID_AA64ISAR2_EL1
Some ID_AA64ISAR2_EL1 fields values are incorrectly indented. Values
have an extra space before the macro to make scanning for them easier.
Add this extra space to the two fields that were missing it.
Sponsored by: Arm Ltd
arm64: Use decimal values for op and CR macros
Using hex here breaks the instruction generated by MRS_REG_ALT_NAME.
Switch to a decimal value.
Sponsored by: Arm Ltd
