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
cpufreq_dt: fix attach for single CPU
The 'opp-shared' property is required, but has no meaning for a
single-processor system, and is thus not present in such device trees as
the BeagleBone Black. Expand the check so we do not fail attachment in
this case.
This is a partial cherry-pick from the original commit. Intended for
merge into releng/14.5.
PR: 297788
Reported by: Rick Richard <rick at sloservers.com>
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48124
(cherry picked from commit def7999c2ccddc9a303a65c0bea22976e79d8613)
generic_ehci_fdt: fix driver softc size
This subclass declares its own softc structure adding necessary members
after the embedded ehci_softc_t. The full size of the struct must be
included in the driver declaration, otherwise the allocation backing the
softc is not guaranteed to be large enough.
Reported by: KASAN
Reviewed by: jrtc27, manu
Fixes: 7a58744fd0f1 ("Split out the attachment from the generic-ehci driver")
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57951
(cherry picked from commit d5332d3a904242cb82e7dbf35e4aeec7c2df4402)
crashinfo: Create core.txt.last symlink
When saving a coredump, savecore(8) maintains .last symlinks for the
info and vmcore artifacts, but not for the crashinfo text report.
Make crashinfo(8) create the link, pointing at the current
core.txt.<bounds> file.
This makes /var/crash/core.txt.last track the same core dump as
info.last and vmcore.last.
[mhorne: I tweaked the submission, such that the link will be created as
soon as the core.txt.X file is generated; not only after a successful
report has been written.]
Signed-off-by: Ricardo Branco <rbranco at suse.de>
Reviewed by: mhorne
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2199
[2 lines not shown]
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
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
openssl: Fix multiple vulnerabilities
This is a rollup commit from upstream to fix:
Avoid full read buffer allocation when buffering DTLS records
ssl/record: lower the DTLS unprocessed_rcds queue limit
Fix heap buffer overflow (8-byte OOB write) in AES-WRAP-PAD unwrap
Add a test for restricting growth in cmp cert cache
Fix unbounded cert cache growth in cmp
Fix Remote NULL deref in ossl_cmp_calc_protection() via crafted protectionAlg
Approved by: so
Obtained from: OpenSSL
Security: FreeBSD-SA-26:61.openssl
Security: CVE-2026-54874
Security: CVE-2026-63072
Security: CVE-2026-63074
Security: CVE-2026-63076
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
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]
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
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
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]
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]
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]
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
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
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
snd_uaudio: Define USB IDs in usbdevs
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
(cherry picked from commit 3e67b90c55b44579c2f73c2fbdeac54087c7495f)
sound: Retire sndcard_func
sndcard_func is used as an ivar which passes around device info to the
PCM and MIDI children in snd_csa(4) and snd_emu10kx(4). Simplify this
and retire the need for sndcard_func, by 1) making an ivar only what
used to be stored in sndcard_func->varinfo, 2) replacing
sndcard_func->func with a child comparison, where needed, for instance
in csa_detach().
sndcard_func is harmless in reality, but there is no reason to have the
additional complexity. This way we also avoid the structure allocations.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
(cherry picked from commit a753ca9c3f0644611e7dfb453af61896fed6c897)
