ktls: Fix capability checks in ktls_reset_receive_tag()
IFCAP2_RXTLS4 and IFCAP2_RXTLS6 are bit numbers, not masks, so
ktls_reset_receive_tag() tested if_capenable2 against 0 for IPv4 and against the
RXTLS4 bit for IPv6. An IPv4 connection with NIC receive TLS offload thus never
got a new receive tag after its packets moved to another interface, and fell
back to software decryption for good.
c721694 fixed the same checks in ktls_alloc_rcv_tag(); use IFCAP2_BIT() here
as well.
Fixes: fe8c78f ("ktls: Add full support for TLS RX offloading via network interface.")
Approved by: gallatin, kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D60757
ktls: Take the receiving interface of each packet in sbappend_ktls_rx()
sbappend_ktls_rx() read the receiving interface of each packet header it
demotes from the chain's first mbuf, whose header it had zeroed on the first
pass. A chain of two packets or more thus had no interface, and a change of
input interface went unnoticed: the TLS receive tag stayed on the old interface
until a later append of one packet.
Read it from the packet being demoted, as the decrypted mark is.
Fixes: fe8c78f0d202 ("ktls: Add full support for TLS RX offloading via network interface.")
Approved by: gallatin
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D60758
iwm: add iwm_enable_ac_txq(); use it for command queue setup
Port iwm_enable_ac_txq() from OpenBSD. It's effictively the
command FIFO path in the existing iwm_enable_txq().
The OpenBSD driver does a bunch of TX aggregation queue setup in
iwm_enable_txq() which isn't relevant here just quite yet and
it doesn't currently hurt to leave the existing one here
whilst I figure out the next steps.
Locally tested:
* 3160, 7260, 8260, 9260 - STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60696
iwm: add phy/mac context tasks; clean up task stop; add net80211 MAC methods
* Add phy/mac tasks, the phy task is currently a placeholder
* Add in the MAC methods from net80211 that are called whenever
the VAP mode needs updating
* Mark the hardware as STOPPED during shutdown so scheduled tasks
don't run
The fun side of this work:
* detaching net80211 causes the parent method to be called which leads
to iwm_stop() being called, and at least one of the entry paths
into iwm_stop() has IWM_LOCK held, and we can't do a taskqueue_drain()
or taskqueue_drain_all() call with any lock held as it will sleep.
* the net80211 detach path is calling at least one of the MAC methods
during detach, and since the taskqueue is being deleted /before/
the net80211 detach path, we have to make sure nothing is actually
going to do taskqueue work after that!
[12 lines not shown]
devfs: Explicitly disable inotify
In principle, inotify can be used to leak timing information about I/O
device accesses by privileged process, which might be sensitive, e.g.,
in the case of /dev/input. See https://inoti.fyi/#1-linux-inter-keystroke-timing
In practice this does not work since I/O to devfs nodes does not go
through vnodes, so the INOTIFY() calls in various VOP hooks do not fire.
But, let's explicitly define a no-op VOP_INOTIFY to help ensure that no
one tries to "fix" this bug.
Alternately we could simply ignore VCHR/VBLK vnodes in vn_inotify().
However, maybe someday it'll be desirable to enable inotify for specific
device files, in which case the filtering should live in devfs.
Add a regression test.
Reported by: Sudheendra Raghav Neela <sneela at tugraz.at>
Reviewed by: kib
[8 lines not shown]
HBSD: Garbage collect old DNSSEC root key material
This completes the migration to the new DNSSEC key material.
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
MFC-to: 15-STABLE
X-MFC-with: 505acb182e96baee81bb398c490555b681565f8e
(cherry picked from commit 4eeb3fe08eae9b1978b812f22c1a3d9045d8c823)
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
(cherry picked from commit 845ac0b0b8b795eb98b3841ddd2a62245693d0db)
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
HBSD: Update the link to the new DNSSEC key
This is that follow-up commit mentioned in the commit referenced below.
Another follow-up commit will revoke the old DNSSEC key.
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
MFC-to: 15-STABLE
X-MFC-with: 0429b93d1e93f012ffffe9f068d3b0a4238af8a6
(cherry picked from commit 505acb182e96baee81bb398c490555b681565f8e)
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
(cherry picked from commit 7a8776b30fb03ee4caa092759ab1096e9fc035f0)
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
HBSD: Update DNSSEC root key material
This key material was generated with the following command:
==== BEGIN COMMAND ====
$ drill -t DNSKEY . > \
share/keys/hbsd-update/trusted/dnssec.key-2026-10-13
==== END COMMAND ====
The root DNSSEC key material was updated on 11 Oct 2026.
Note that this commit only creates the new file. It does not switch to
this new key material. Updating the link will be committed in a
follow-up commit.
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
See-Also: https://www.icann.org/resources/pages/ksk-rollover-en
MFC-to: 15-STABLE
(cherry picked from commit 0429b93d1e93f012ffffe9f068d3b0a4238af8a6)
[3 lines not shown]
amd64/vmm: Don't advertise support for performance counters
vmm doesn't implement them, and after commit 2272fac218a8
("hwpmc: Add support for AMD-only IRPERF in hwpmc PERF class"), FreeBSD
guests fail to boot since they access the unimplemented IRPERF MSR.
MFC after: 1 week
(cherry picked from commit c83e075d72f62c91cb27dd644a62d6a6f5bd56ba)
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
(cherry picked from commit e211e04735316fb82e6cfef6536b0976105961fb)
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
devfs: Explicitly disable inotify
In principle, inotify can be used to leak timing information about I/O
device accesses by privileged process, which might be sensitive, e.g.,
in the case of /dev/input. See https://inoti.fyi/#1-linux-inter-keystroke-timing
In practice this does not work since I/O to devfs nodes does not go
through vnodes, so the INOTIFY() calls in various VOP hooks do not fire.
But, let's explicitly define a no-op VOP_INOTIFY to help ensure that no
one tries to "fix" this bug.
Alternately we could simply ignore VCHR/VBLK vnodes in vn_inotify().
However, maybe someday it'll be desirable to enable inotify for specific
device files, in which case the filtering should live in devfs.
Add a regression test.
Reported by: Sudheendra Raghav Neela <sneela at tugraz.at>
Reviewed by: kib
[8 lines not shown]
bhyve: Fix handling of framebuffer resizing
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
fb51ddb20d57 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
[8 lines not shown]
bhyve: Improve HDA stream descriptor validation
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
[2 lines not shown]
bhyve: Fix handling of the xhci event ring
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
[7 lines not shown]
sound: Revalidate after reacquiring locks when resizing buffers
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
[13 lines not shown]
sound: Check for errors from sndbuf_resize()
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.
[7 lines not shown]
tcp/rack: Fix a potential overflow in rack_update_pcm_ack()
The RACK stack's path capacity measurement module maintains an array of
samples, updated when the stack receives an ACK. The array grows as
needed, but code which handles the expansion is susceptible to remotely
triggerable overflow. This could lead to underallocation and a ~512KB
out-of-bounds write.
Fix this by bounding the sample array size.
Approved by: so
Security: FreeBSD-SA-26:70.tcp
Security: CVE-2026-101307
Reviewed by: glebius, markj
Reported by: Nozomi Networks Security Research
(cherry picked from commit 57818a298ee1b7e907df7759346f9f4a11370d63)
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
