HBSD: Various fixups in libthr
HardenedBSD has diverged ever so slightly in the threading library. This
caused a world build issue after recent changes by FreeBSD.
Signed-off-by: Shawn Webb <shawn.webb at hardenedbsd.org>
MFC-to: 15-STABLE
X-MFC-with: 5fb07bbcd5d5d9a865d9e7765fb93e9ba5edef1c
machine/ieeefp.h: include <sys/cdefs.h>
The <machine/ieeefp.h> headers wrap their deprecated FPU control
prototypes in __BEGIN_DECLS/__END_DECLS but rely on the includer to
have pulled in <sys/cdefs.h>. Including <floatingpoint.h> first on
arm, arm64, powerpc and riscv (or amd64 <machine/ieeefp.h> with
__IEEEFP_NOINLINES__) fails with "unknown type name '__BEGIN_DECLS'".
This breaks e.g. devel/py-pyinstaller.
Suggested by: jhb
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D59659
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
[10 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
[4 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
[11 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 and CHANNEL_SETBLOCKSIZE are returned to
userspace.
[6 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
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.
[4 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
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
[5 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
Reviewed by: christos
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60678
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
[5 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
[4 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
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
snd_hda: use the pin ELD to select DisplayPort audio framing
hdaa_audio_setup() reads the converter widget's ELD when choosing
between HDMI and DisplayPort audio infoframes. ELD is stored on the
output pin, so the converter has no ELD and the driver selects HDMI
framing even when the connected display uses DisplayPort.
Read the ELD from the output pin to select the correct audio framing.
The equivalent change was tested on DragonFly BSD with an Intel Kaby
Lake display-audio codec and an LG HDR 4K monitor connected over
DisplayPort. Before the change, converter node 2 had no ELD, while
output pin 5 had an 83-byte ELD identifying DisplayPort. Captured driver
commands programmed HDMI audio infoframe bytes (84 01 0a 70 01 00 00
00). After applying the change and rebooting, the commands used the
existing DisplayPort form (84 1b 44 01 00 00 00), and console tones and
desktop audio were audible.
PR: 299094
[4 lines not shown]
pcm.4: Remove DIAGNOSTICS section
These diagnostics do not exist anymore.
MFC after: 1 week
(cherry picked from commit 25faf861089ca119528ea4da39fe594b1c5ca55a)
rc.d/mountd: Do not require /etc/exports
mountd exits if it cannot read any exports files. Requiring
/etc/exports, however, unconditionally stops mountd from starting on a
server that exports ZFS datasets only (/etc/zfs/exports).
Let sbin/mountd handle requirements itself, instead of hardcoding
/etc/exports, which is also wrong, because different files can be
specified in mountd_flags.
This patch also works with nfsv4_server_enable="YES", by preserving the
behavior of failing to start if there is no "V4:" line in the exports
file, which is missing by default on ZFS-only exports.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: rmacklem, markj, emaste
Differential Revision: https://reviews.freebsd.org/D60044
(cherry picked from commit 26203cca52621c215f60640bf59128dcd9780be7)
nfscl: Fix oddball cases for session slot release
We have identified some cases where silent slot loss can occur
when operations on NFS mounts are aborted. We experience this
when using NFSv4.2, but it likely also occurs with NFSv4.1.
A slot is acquired for compound operations by nfsv4_setsequence()
and freed by newnfs_request(). Any call path that abandons the
compound before reaching newnfs_request() loses the slot permanently.
We identified four call sites where this happens, one of
which where it actually does happen for us in a semi-reproducible
way, which allowed us to develop a candidate patch, attached.
The patch adds one function, nfsv4_freeunsentslot(), to
nfs_clcomsubs.c. It is called from each of the four call
sites: nfsrpc_writerpc(), nfsrpc_writeds(), and two in
nfsrpc_setextattr().
[11 lines not shown]
