virtio_gpu: use an X8R8G8B8 resource on big-endian guests
The virtio-gpu resource formats are defined by byte order in memory,
while vt(4) and the X server (through vt_fb and the fb mmap) write
native 32-bit 0x00RRGGBB pixels into the shadow framebuffer. On a
big-endian guest such as powerpc64 those pixels land in memory as
00 RR GG BB, which the host interprets under B8G8R8X8 with red and
blue swapped and the padding byte taken as blue: white renders yellow
and blue renders black.
Request X8R8G8B8 on big-endian guests instead, which is also what the
Linux driver does (DRM_FORMAT_HOST_XRGB8888). Reproduced with a colour
test pattern on a powerpc64 QEMU pseries guest using the identically
coded out-of-tree fork of this driver (graphics/virtio-gpu-qemu-kmod);
little-endian guests are unchanged.
Differential Revision: https://reviews.freebsd.org/D60085
Approved by: jhibbits
MFC after: 1 week
[3 lines not shown]
virtio_gpu: use an X8R8G8B8 resource on big-endian guests
The virtio-gpu resource formats are defined by byte order in memory,
while vt(4) and the X server (through vt_fb and the fb mmap) write
native 32-bit 0x00RRGGBB pixels into the shadow framebuffer. On a
big-endian guest such as powerpc64 those pixels land in memory as
00 RR GG BB, which the host interprets under B8G8R8X8 with red and
blue swapped and the padding byte taken as blue: white renders yellow
and blue renders black.
Request X8R8G8B8 on big-endian guests instead, which is also what the
Linux driver does (DRM_FORMAT_HOST_XRGB8888). Reproduced with a colour
test pattern on a powerpc64 QEMU pseries guest using the identically
coded out-of-tree fork of this driver (graphics/virtio-gpu-qemu-kmod);
little-endian guests are unchanged.
Differential Revision: https://reviews.freebsd.org/D60085
Approved by: jhibbits
MFC after: 1 week
[2 lines not shown]
iwm: add return status to set/clear prph bits
This brings these functions inline with OpenBSD
Locally tested:
* 3160, STA mode
* 7260, STA mode
* 8260, STA mode
* 9260, STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D60211
iwm: update phy context routines; add HT channel width parameter
Update the phy context routines to match what the openbsd snapshot
is doing. This involves some HT channel width stuff which although
I am not doing HT right now, it was juts easier to sync these
entirely versus just a partial sync.
* Update the phy context routines to match what openbsd is doing
* Although the openbsd driver has an iwm_phy_ctxt_update() routine
instead of add and modify, I'm leaving it as-is for now.
A bunch of refactoring is going to need to be done to properly
use an iwm_phy_ctxt_update() call and I didn't want to tackle
that in here.
* Add a UHB firmware capability phy context call; I can't test it
but it's mostly copy/paste.
* Add in a util to turn ieee80211_channel into the 'sco' variable
(the HT low/hi parameter) since it's done in openbsd in a
slightly different way.
[10 lines not shown]
iwm: bring IWM_CSR_HW_IF_CONFIG_REG programming in line with openbsd
bring the iwm_nic_config() / IWM_CSR_HW_IF_CONFIG_REG programming
in line with openbsd.
Locally tested:
* 3160 STA mode
* 7260 STA mode
* 8260 STA mode
* 9260 STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60081
iwm: add DQA (dynamic queue assignment)
This is the minimum set of DQA bits from iwm at the given openbsd
commit place.
* add a method to map ac to queue / ring
* use the DQA command queue if needed
* glue to wire it up
Locally tested:
* Intel 7260, STA mode
* Intel 9260, STA mode
* Intel 8260, STA mode
* Intel 3160, STA mode
Obtained from: OpenBSD a6e25c727a2214219715b51ba6af2221d7e0d674
Differential Revision: https://reviews.freebsd.org/D60080
nfs_nfsdsocket.c: Fix "nfsstats -d" for ERELOOKUP
When ERELOOKLUP is returned by a file operation
(always vop_lookup?) the operation is retried without
doing nfsrv_statsend().
This patch fixes this problem,
The only effect of the bug was bogus "nfsstat -d"
output.
PR: 298534
(cherry picked from commit 9a237074d380233e93a17ddee6b155cc2f90ee96)
nfs_nfsdsocket.c: Fix "nfsstats -d" for ERELOOKUP
When ERELOOKLUP is returned by a file operation
(always vop_lookup?) the operation is retried without
doing nfsrv_statsend().
This patch fixes this problem,
The only effect of the bug was bogus "nfsstat -d"
output.
PR: 298534
(cherry picked from commit 9a237074d380233e93a17ddee6b155cc2f90ee96)
diff: support -qq to output absolutely nothing
This is similar to `cmp -s`, but can be combined with:
-B --ignore-blank-lines
-b --ignore-space-change
-w --ignore-all-space
To only report a difference if it doesn't involve whitespace
Reviewed by: des, bapt, markj (previous version), ziaee (man page)
MFC after: 1 week
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D46717
fusefs: fix a deadlock caused by daemons that never initialize
If a daemon never responds to FUSE_INIT, but some process attempts to
access the mountpoint, and a different process (possibly the daemon
itself) attempts to unmount, a deadlock would result.
Fix this bug by blocking any thread that enters fuse_vfsop_root until
the daemon responds to FUSE_INIT or it times out. That will block any
thread attempting to lookup a path in the fuse mountpoint, before it
even gets to fuse VOPs. Remove less thorough initialization checks in
fuse_ticket_fetch and fuse_vnop_access that are no longer necessary.
And add a test case.
PR: 287431
Sponsored by: ConnectWise
Reviewed by: js
Differential Revision: https://reviews.freebsd.org/D59737
(cherry picked from commit 0bd6348b52e1991fafc55128173c989dab36dfd9)
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
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]
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: 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
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]
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]
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]
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
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
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]
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]
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
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]
