These two moved from trusted to untrusted.
Approved by: so
Security: FreeBSD-SA-26:73.caroot
Fixes: 21ac476142 ("ObsoleteFiles.inc: Add dropped certificates")
(cherry picked from commit dd6a1fef0e)
Regenerate using certificate data from NSS 3.131.1.
Upstream dropped emSign_ECC_Root_CA_-_G3.pem entirely; we deliberately
move it to untrusted instead to block its reintroduction through e.g.
an outdated copy of security/ca_root_nss.
Approved by: so
Security: FreeBSD-SA-26:73.caroot
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D60906
(cherry picked from commit 82af7f44eb)
Regenerate using certificate data from NSS 3.123.1.
Approved by: so
Security: FreeBSD-SA-26:73.caroot
MFC after: 1 week
Reviewed by: kevans
(cherry picked from commit 07b52233e8)
(cherry picked from commit 09bb6a62d0)
* Get certdata.txt directly from the NSS Mercurial repository, rather
than from the Mozilla Firefox repository which imports it from NSS at
irregular intervals.
* Instead of always fetching the latest certdata.txt, fetch a specific
version. For this commit, we set this to the version that was last
imported in May 2025.
* Add a refrence to the MPL to the generated files.
* Regenerate with latest OpenSSL. This is purely cosmetic; mostly, the
certificate names now contain less unnecessary whitespace and some
elements are quoted.
Approved by: so
Security: FreeBSD-SA-26:73.caroot
MFC after: 1 week
Reviewed by: michaelo, kevans
Differential Revision: https://reviews.freebsd.org/D56620
(cherry picked from commit ce33d6396a)
(cherry picked from commit 7e064a35a7)
Until now, the untrusted directory has been maintained manually. Modify
the script used to maintain the trusted directory so it can handle both.
While here, clean it up a bit.
Approved by: so
Security: FreeBSD-SA-26:73.caroot
MFC after: 1 week
Reviewed by: mandree, markj
Differential Revision: https://reviews.freebsd.org/D51774
(cherry picked from commit b88b0bb784)
(cherry picked from commit ca80ae39e8)
The rfb code maintains an array of CRCs for 32x32 tiles in the
framebuffer. This array is sized statically based on the rfb code's
notion of the maximum framebuffer size, which changed in commit
fb51ddb20d without updating the rfb code.
Morever, writes to the framebuffer BAR can modify the recorded height
and width of the framebuffer. These values were not validated against
the maximum at all, unlike the parameters set via bhyve config.
Fix these problems:
- Define the maximum width and height in a shared header file so that
they do not get out of sync again.
- In pci_fbuf_render(), don't resize the console if the new dimensions
are too large.
- Add a mutex to synchronize framebuffer BAR I/O with the rfb thread.
Approved by: so
Security: FreeBSD-SA-26:72.bhyve
Security: CVE-2026-101311
Fixes: fb51ddb20d ("bhyve: increase fbuf display resolution limit")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60680
The length of each block in the stream must be non-zero. This is
assumed in hda_transfer(), otherwise an out-of-bounds read or write is
possible.
Use atomic loads to access stream descriptor fields, since they are
guest-controlled. Make sure that the descriptor array is suitably
aligned so that we can drop the __packed annotation from the structure
definition; per section 3.3.42 of the HDA spec the BDL pointer is
supposed to be 128-byte aligned, in fact.
Approved by: so
Security: FreeBSD-SA-26:72.bhyve
Security: CVE-2026-101310
Reported by: Brian Delgado from Intel using Anthropic Opus 4.8
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60678
rts->erst_p and rts->erstba_p are pointers to guest-controlled memory
which describe the event rings and pending event array, respectively.
The device model was not validating the size nor saving the value.
As a result, the bounds checks in pci_xhci_insert_event() were
susceptible to TOCTOU races.
Fix pci_xhci_rtsregs_write() to save the ring size in a softc field.
Validate that the size isn't larger than the maximum allowed by the XHCI
specification (64KB, or 4096 TRBs).
When processing TRBs, make sure we don't load fields more than once.
Make sure that pci_xhci_trb_next() doesn't return a pointer to host
memory. When handling ERDP writes, make sure that the guest-supplied
address is actually a pointer into the TRB array, and ignore the write
if not.
Approved by: so
Security: FreeBSD-SA-26:72.bhyve
Security: CVE-2026-101309
Reported by: Brian Delgado from Intel using Anthropic Opus 4.8
Differential Revision: https://reviews.freebsd.org/D60677
sndbuf_resize() and sndbuf_remalloc() drop the channel lock in order to
allocate the new buffer(s) with M_WAITOK. Before doing that they verify
that the buffer is not mapped, but this could change while the lock is
dropped, as there is no higher-level synchronization which prevents
buffer resize (e.g., via the SNDCTL_DSP_SETBLKSIZE ioctl) from happening
concurrently with mmap. Thus, these checks are insufficient.
Modify sndbuf_resize() and sndbuf_remalloc() to revalidate after
reacquiring the lock. Extend them to check for a couple of channel
flags, mirroring the check in chn_resizebuf(). Modify chn_resizebuf()
to revalidate state after reacquiring the channel lock.
We could also allocate new buffers with M_NOWAIT and so avoid dropping
the lock. Then, I think we could go even further and invoke
CHANNEL_SETBLOCKSIZE and CHANNEL_SETFRAGMENTS with the channel lock
held. But really it would be better to ensure that dsp operations are
serialized; there is no reason for mmap and chn_resizebuf() to be able
to run in parallel, we should not be relying on the channel lock for
this. So, let's keep a more minimal approach here.
Add a simple regression test.
Approved by: so
Security: FreeBSD-SA-26:71.sound
Security: CVE-2026-101308
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60554
Most implementations of CHANNEL_SETBLOCKSIZE and CHANNEL_SETFRAGMENTS
were not checking this. This is probably not a big problem: it's
unlikely for sndbuf_resize() to fail due to the refcount check in this
case since it's operating on the hardware buffer, which doesn't get
mmaped. But, I will add more reasons for it to fail in the next patch,
so let's be more careful.
This change modifies various CHANNEL_SETBLOCKSIZE implementations to
check for errors. In some cases I reordered things to avoid updating
driver state until after sndbuf_resize() succeeds.
Return 0 from CHANNEL_SETBLOCKSIZE to indicate an error, as it otherwise
returns the new block size. We could change the interface to return
both an error number and a block size, but that would break at least one
out-of-tree driver and I wish to avoid that here. Make sure that errors
from CHANNEL_SETFRAGMENTS are returned to userspace.
Approved by: so
Security: FreeBSD-SA-26:71.sound
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60553
When a TCP timer is stopped, t_timers[] is set to SBT_MAX. Adding the
corresponding t_precisions[], if it is not zero, would result in
overflows in tcp_timer_next(). To avoid this, skip stopped timers.
The problem was identified while debugging uperf by Lukas Book and
an initial patch was provided by him. The committed patch was
suggested by glebius.
The problem can be observed by running netstat -nxptcp and looking for
negative timer values and by observing very long running timers in
some cases.
Approved by: so
Security: FreeBSD-EN-26:27.tcp
Reported by: Lukas Book <[email protected]>
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D58484
(cherry picked from commit 52b7cbcb78)
(cherry picked from commit 85485a570d)
All communication between hastd nodes and internally between hastd and
its worker children passes through the same pair of send / receive
functions. The receive function uses recv(2) with the MSG_WAITALL flag,
which in theory means we should never get a short read. However, when
handing off a socket to a worker child, we also pass a variable-length
string identifying the type of socket we're passing, and reading this
string relies on a short read. This used to work because the arrival of
the descriptor would interrupt the recv(2) call, but this bug was fixed
when the AF_UNIX code was rewritten a while ago and hastd has been
broken ever since.
Fixing the length of the protocol name to four characters including the
terminating null solves the short-read bug by never requiring a short
read (nothing else in hastd requires one).
Note that this issue appears to have been reported independently first
by Alessandro Sagratini in PR 292322 and then by Martin Vidovic in
D57511. I ended up going in a different direction than Martin's patch,
but his analysis was invaluable, hence the double credit below.
Approved by: so
Security: FreeBSD-EN-26:26.hastd
PR: 292322
Reported by: Martin Vidovic <[email protected]>
MFC after: 1 week
Event: EuroBSDcon DevSummit 2026
Reviewed by: xtronom_gmail.com, kevans, glebius, gjb
Differential Revision: https://reviews.freebsd.org/D59521
(cherry picked from commit b7e5c2e008)
(cherry picked from commit 9401bfb061)
The proto-libnv implementation embedded in hastd pads names and values
out to the nearest multiple of eight bytes, but leaves the padding
uninitialized, leaking up to 14 bytes of recycled heap per pair in a
message.
While here, switch from bcopy() to memcpy().
Approved by: so
Security: FreeBSD-EN-26:26.hastd
MFC after: 3 days
Reviewed by: kevans, emaste
Differential Revision: https://reviews.freebsd.org/D59343
(cherry picked from commit 911bda7cff)
(cherry picked from commit e4b16e7868)
A HAST message can be empty, in which case ebuf_add_tail() does nothing
and ebuf_data() returns NULL because the size of the ebuf is zero, but
hast_proto_recv_hdr() asserts that the return value is not NULL,
resulting in an immediate crash if hastctl or hastd receive an empty
message. This is trivially reproducable by running `hastctl status` or
`hastctl role init` (as the rc script does prior to stopping hastd).
To avoid this, don't try to grow the ebuf or receive additional data
if the header size is zero.
Approved by: so
Security: FreeBSD-EN-26:26.hastd
PR: 298085
MFC after: 3 days
Reviewed by: kevans, gjb
Differential Revision: https://reviews.freebsd.org/D59306
(cherry picked from commit 8646d65b45)
(cherry picked from commit 4d83686bc3)
This is a backport of an upstream commit to fix:
dtls: reset init_off before retransmitting a message
Approved by: so
Security: FreeBSD-SA-26:68.openssl
Security: CVE-2026-84782
The FD_RESOLVE_BENEATH flag is supposed to be sticky. It's set when you
receive an fd from a different jail and preserved by openat(<dfd>) etc..
However, if you send the fd to yourself, the flag is stripped since
SCM_RIGHTS message don't preserve file descriptor flags.
Fix this by preserving those flags and checking for UF_RESOLVE_BENEATH
in restrict_rights().
Approved by: so
Security: FreeBSD-SA-26:66.jail
Security: CVE-2026-101306
Fixes: 350ba9672a ("unix: Set O_RESOLVE_BENEATH on fds transferred between jails")
Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58317
(cherry picked from commit 586e2b3d89)
(cherry picked from commit 441885dcff)
The FD_RESOLVE_BENEATH flag was intended to try to resolve bugzilla PR
262179 without entirely disallowing fd passing between jails. However,
one can use renameat() to bypass the restriction: upon receiving a
directory fd with FD_RESOLVE_BENEATH set, a jailed process can still
move its CWD or one of its ancestors to the directory, and just cd
out of its jail root.
So disallow renameat() when either the source or destination directory
fds has FD_RESOLVE_BENEATH set, like we do with fchdir() and fchroot()
to prevent similar escapes.
Approved by: so
Security: FreeBSD-SA-26:66.jail
Security: CVE-2026-101305
PR: 262179
Reported by: [email protected]
Reviewed by: olce, kib
Differential Revision: https://reviews.freebsd.org/D59875
When an fdescfs mount has the nodup option set, fdesc_lookup(/dev/fd/n)
returns the vnode referenced by file descriptor n, rather than returning
an fdescfs vnode. This meant that fd metadata attached to fd n was not
preserved when reopening the file, which is contrary to the expected
semantics for capsicum rights and the UF_RESOLVE_BENEATH fd flag. For
regular fdescfs mounts, this metadata is copied via dupfdopen().
Fix the problem by passing up this metadata through the nameidata
structure. Thus, if one opens /dev/fd/n, the returned fd will inherit
UF_RESOLVE_BENEATH and the capability rights of fd n. Add some
regression tests as well.
Approved by: so
Security: FreeBSD-SA-26:66.jail
Security: CVE-2026-101304
Reported by: Jan Bramkamp
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59886
These routines let one compute the intersection of two sets of filecaps
or capability rights, just as filecaps_merge() and cap_rights_merge()
compute the union. This will be useful in an upcoming patch.
filecaps_intersect() is complex due to the need to merge sets of ioctls.
For now this is implemented with a dumb nested loop on the basis that
ioctl lists are typically short enough that this is fine. It may be
better to instead sort the two lists first and step through them
together.
No functional change intended.
Approved by: so
Security: FreeBSD-SA-26:66.jail
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59885
In a couple of places we want to know whether someone has limited rights
on an fd. There, we want a predicate which determines whether the set
of rights is smaller than CAP_ALL, and whether there are explicit ioctl
or fcntl lists. Factor this out into a helper function, in preparation
for use elsewhere.
No functional change intended.
Approved by: so
Security: FreeBSD-SA-26:66.jail
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59884
When performing an unconnected sendto() on a v6 UDP socket in a classic
jail, we were not applying the usual policy of replacing the loopback
addr with the jail's primary IP. Compare with, e.g., udp6_connect() or
the IPv4 udp_send(). Fix that.
Approved by: so
Security: FreeBSD-SA-26:69.udp
Security: CVE-2026-101303
Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li,
and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai
Reviewed by: bz, glebius
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59772
(cherry picked from commit fecb9537a8)
(cherry picked from commit 809221661a)
If the entire plaintext is zero-filled, the backwards walk in
tls13_find_record_type() would return the offset of the last byte of the
TLS header. This causes an underflow when decrypting, resulting in a
null pointer dereference.
Fix the bug and add a regression test.
Approved by: so
Security: FreeBSD-SA-26:67.ktls
Security: CVE-2026-101302
Reviewed by: gallatin, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59767
(cherry picked from commit 7c5e457d3a)
(cherry picked from commit fc1a02c93b)
TLS receive offload is really only beneficial for in-kernel use cases
(such as NFS over TLS) or when using a hardware offload. In addition,
several recent SAs have involved the TLS receive path, but the only
current mitigation for those is to disable TLS offload entirely.
Approved by: so
Security: FreeBSD-SA-26:67.ktls
Reviewed by: ziaee, gallatin, markj
Relnotes: yes
Sponsored by: Netflix
Sponsored by: Chelsio Communications
Co-authored-by: John Baldwin <[email protected]>
Differential Revision: https://reviews.freebsd.org/D57974
(cherry picked from commit 08cda4bcd4)
(cherry picked from commit f80f8c38fa)
semop() may sleep waiting for a semaphore. Upon waking up, it checks to
see if the set's sequence number has changed, indicating that the set
was removed. The sequence number is not wide enough to prevent a false
negative due to wraparound, in which case the subsequent access of
`semakptr->u.__sem_base[sopptr->sem_num]` may be out of bounds. This
race can be leveraged to elevate privileges.
Fix this by introducing a 64-bit sequence number for each semaphore
pool. This is wide enough to make the race impossible to hit. Allocate
a separate array for them, as we cannot really change the layout of
struct semid_kernel since some userspace tools (e.g., ipcrm(1)) embed
the layout.
While here, use semvalid() instead of open-coding its implementation,
convert a couple of flags to be bool, and use a better variable name to
store required permissions.
Approved by: so
Security: FreeBSD-SA-26:64.sysvsem
Security: CVE-2026-58098
Reported by: Reo Shiseki
Reported by: Andrew Griffiths
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59347
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
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
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
Per RFC1717 section 5.1.3, the option length must be at least three.
Processing an undersized option would trigger a large out-of-bounds
write.
Approved by: so
Security: FreeBSD-SA-26:60.ppp
Security: CVE-2026-58096
PR: 271910
Reported by: Robert Morris
Reported by: Décio Brandão (0xDBJ)
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58554
(cherry picked from commit b9d07a4308)
(cherry picked from commit 30b4bdd451)
Each byte of the address is represented by a pair of characters, so we
should be multiplying len by 2 when figuring out how much buffer space
we have. Previously, a sufficiently large option could cause an
overflow of the global "result" buffer.
Approved by: so
Security: FreeBSD-SA-26:60.ppp
Security: CVE-2026-58095
Reported by: Joshua Rogers <[email protected]>
Tested by: Décio Brandão (0xDBJ)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58555
(cherry picked from commit e004ff15f8)
(cherry picked from commit 607c41d8f8)
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
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 1c3c698ba4 and 1c40b15971
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.
Also fix a bug at the end of pmc_process_exec():
pmc_detach_one_process() will call pmc_remove_process_descriptor() for
us.
Approved by: so
Security: FreeBSD-SA-26:56.hwpmc
Security: CVE-2026-58089
Reported by: netchild
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59102
The files were incorrectly reporting 3.5.1 instead of 3.0.21.
This is a direct commit to stable/14 as stable/15 and later are on
OpenSSL 3.5.
Approved by: so
Security: FreeBSD-26:21.openssl
PR: 297144
Fixes: d03be8cf ("crypto/openssl: make vendor imports easier/less error prone")
For releng/14.4 the version was updated to 3.0.20.
(cherry picked from commit 2e04d98688)
The check for the extended signature table was backwards, so we always
ignored it.
We should verify that the extended signature table fits within the total
image size.
Approved by: so
Security: FreeBSD-EN-26:20.microcode
Reviewed by: jrm, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D57209
(cherry picked from commit 0beb172898)
(cherry picked from commit 38cbd2588f)
In an ELF coredump, each dumped vm_map_entry is represented by a
segment. __elfN(coredump) first computes the number of segments by
looping over the vm_map entries (in each_dumpable_segment()), then
allocates a buffer to hold the ELF header and program headers, then
loops over the entries again to populate the program headers.
each_dumpable_segment() holds the vm_map read lock, but that lock is
dropped between the two calls. If the map is shared with another
process, via rfork(), then the map can change. cb_put_phdr() did not
account for this, and so could write out of bounds.
Add a check to prevent this; simply do not write out excess segments.
Approved by: so
Security: FreeBSD-SA-26:55.elf
Security: CVE-2026-58088
Reported by: Maik Muench of Secfault Security
Reviewed by: kib, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58416
These commands take a snapshot of the size of a semaphore set, then drop
the lock and malloc an appropriately sized array before reacquiring the
lock. A comment explains why this is (probably) safe. Unfortunately,
it's wrong; it is indeed possible for a malicious userspace to create
and destroy 2^{15} sets in the window where the lock is dropped. This
race can lead to out-of-bounds reads and writes, and that can be
exploited to elevate privileges.
Replace the assertions with runtime checks.
Approved by: so
Security: FreeBSD-SA-26:54.sysvsem
Security: CVE-2026-58087
Reported by: Maik Muench of Secfault Security
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58421
The test uses a fail point to inject a decryption error in OCF while
sending a ping across the tunnel. The driver should then fail to
respond to the ping and increment the input error counter on the
interface.
Approved by: so
Security: FreeBSD-SA-26:52.if_wg
Security: CVE-2026-58085
Reviewed by: markj
Sponsored by: Chelsio Communications
In particular, handle authentication errors due to bad MACs when
decrypting packets.
Since the current dispatch code assumes synchronous OCF sessions by
design, explicitly reject any created OCF session that is not
synchronous. Software sessions are always synchronous in practice, so
this should be a nop.
Approved by: so
Security: FreeBSD-SA-26:52.if_wg
Security: CVE-2026-58085
Reviewed by: markj
Sponsored by: Chelsio Communications
Mark Johnston