src/sys, branch main

uvideo: fix step=0 infinite loop and int overflow in fbuf_size

2026-07-24T15:07:50Z

Prevent infinite loop in uvideo_vs_negotiation() when a USB camera reports step=0 in its continuous frame interval descriptor. Cast fbuf_size calculation to uint64_t to avoid int overflow for large width/height/bpp combinations. Reported by: emaste

sound: Scale PCM secondary buffers by byte rate

2026-07-24T13:58:14Z

The fixed 128 KiB secondary buffer cap dates from stereo-sized streams. High channel-count or high sample-width OSS streams can consume most of that budget in one graph quantum, leaving too little room for capture catch-up or playback headroom. Keep 128 KiB as the low-rate floor, but derive the effective soft-ring cap from the channel byte rate, clamped to 4 MiB. Use that per-channel cap when resizing the soft buffer and when clamping SNDCTL_DSP_SETFRAGMENT requests. Also clamp SNDCTL_DSP_LOW_WATER to the current soft-buffer size so an impossible readiness threshold cannot make poll/select wait forever. MFC after: 3 weeks Reviewed by: christos Differential Revision: https://reviews.freebsd.org/D58064

cuse: Fix server reference leak in cuse_client_open()

2026-07-24T11:20:09Z

If the server is closing (or the device node is going away), or if devfs_set_cdevpriv() fails, cuse_client_open() returns with the server reference taken at the top of the function still held and the newly allocated client still linked on pcs->hcli. Since cuse_client_free() has not been registered as the cdevpriv destructor at that point, nothing ever undoes this work: every open() that races the is_closing window permanently leaks one server reference and one cuse_client. A leaked reference is fatal on server exit: cuse_server_free() busy-waits in an uninterruptible pause("W", hz) loop until pcs->refs drops to 1, which now never happens, so the exiting server process (e.g. virtual_oss(8)) is left wedged in state "D", immune to SIGKILL, cuse.ko is pinned (kldunload hangs too), and only a reboot recovers. Before 634e578ac7b0 the is_closing error path dropped the reference by calling devfs_clear_cdevpriv(), which ran the cuse_client_free() destructor. That commit moved devfs_set_cdevpriv() after the is_closing check to fix the panic paths, but left both error returns without any cleanup. Fix by calling cuse_client_free() directly on both error paths. The client is fully constructed and linked on pcs->hcli at these points, which is exactly the state cuse_client_free() expects. PR: 296291 Fixes: 634e578ac7b0 ("cuse: Fix cdevpriv bugs in cuse_client_open()") Assisted-By: Claude Opus 4.8 (claude-opus-4-8) Signed-off-by: giacomo MFC after: 2 weeks Reviewed by: christos Pull-Request: https://github.com/freebsd/freebsd-src/pull/2324

snd_uaudio: Don't let an idle stream reprogram a shared UAC2 clock

2026-07-24T11:20:08Z

Some UAC2 devices expose a single Clock Source entity that is shared between their playback and capture interfaces (it appears in both the output and input clock bitmaps). On such a device uaudio(4) programs the sample rate for both directions when a stream starts. If playback runs at a 44.1 kHz-family rate while the idle capture channel is left at its 48 kHz-family default, the capture SET_CUR(UA20_CS_SAM_FREQ_CONTROL) is issued after the playback one and overwrites the rate on the shared clock. The device then runs at ~48 kHz while the playback stream carries 44.1 kHz data. Consuming samples faster than they arrive, the device repeatedly runs out of data, loses sync with the playback stream, and re-locks onto it (audible dropouts, front-panel play/idle flicker). The 48 kHz family is unaffected because both directions then agree on the rate. Fix it in three parts: - Add a shared-clock guard: before issuing SET_CUR to a clock id, if that clock is shared between playback and capture and the other direction is already streaming at a different rate, skip it. The first active stream owns the clock; a later one follows it. - When the recording channel is auto-started only as a source of jitter information for asynchronous playback, align its nominal rate to the playback rate before starting it, so it neither reprograms the shared clock to a conflicting rate nor produces mismatched frame sizes. - Always submit the explicit-feedback SYNC transfer so dev.pcm.%d.feedback_rate stays live as a diagnostic even when a capture stream is present. Reproduced on an OKTO RESEARCH DAC8 STEREO (0x152a:0x88c5), whose vestigial capture interface never streams; the same device plays the 44.1 kHz family correctly under Linux's snd-usb-audio. As a side effect, this patch also fixes the sample rate bug mentioned in the BUGS section of sound(4)'s man page, where a device needs to have the same sample rate set for both playback and recording in order to work properly. PR: 295933 Assisted-By: Claude Opus 4.8 (claude-opus-4-8) Signed-off-by: giacomo MFC after: 2 weeks Reviewed by: christos Pull-Request: https://github.com/freebsd/freebsd-src/pull/2323

icmp: Verify redirect gateway with fib-aware ifa selection

2026-07-24T08:04:27Z

During call to `icmp_verify_redirect_gateway()` ensure using fib-aware source address selection function. Reviewed by: glebius Differential Revision: https://reviews.freebsd.org/D58409

getpgrp(2), getsid(2): allow to call on zombies

2026-07-23T23:50:13Z

Also be more protective in getsid(). Reported by: arrowd Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differrential revision: https://reviews.freebsd.org/D58393

hwpstate_intel(4): use CPU_FOREACH instead of an IPI

2026-07-23T17:40:18Z

Reviewed by: aokblast, kib, olce Differential Revision: https://reviews.freebsd.org/D58336

tcp: make ghost ACK handling more conformant

2026-07-23T16:03:39Z

The latest version of draft-ietf-tcpm-tcp-ghost-acks changed a condition. This should make no substantial difference, but makei it compliant to the latest version of the specification. Reviewed by: rscheff, Peter Lei MFC after: 3 days Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D58411

pf(4) fix NULL pointer dereference in outbound packet path.

2026-07-23T11:27:36Z

Outbound packet which matches rule with source limiter attached, for example: source limiter "crash" id 1 entries 10000 limit 1000 pass out from any to any source limiter "crash" keep state triggers a NULL pointer dereference. The issue was kindly reported and initial version of fix submitted by SecBuddyF, Tencent KeenLab. The submitted diff fixed the issue for failing look up by destination address in outbound packet. dlg@ also pointed out the change should be further improved so NULL pointer dereference is avoided when rule uses nat-to/rdr-to option. OK dlg@ Obtained from: OpenBSD, sashan , f0f215c11e Sponsored by: Rubicon Communications, LLC ("Netgate")

pf: include direction in fragment key

2026-07-23T11:27:30Z

pf(4) currently ignores fragment direction (in vs. out) in pf_frnode_compare() function. Issue noticed and reported by Frank Denis OK @bluhm Obtained from: OpenBSD, sashan , eaa2c80721 Sponsored by: Rubicon Communications, LLC ("Netgate")