src/sys/dev, 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

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

uvideo: fix printf type

2026-07-22T16:37:52Z

Reported by: vishwin

uvideo: validate frame descriptors and fix integer overflows in size computation

2026-07-22T15:10:58Z

uvideo: use size_t for sc_mmap_count and loop index in reqbufs

2026-07-22T15:10:58Z

uvideo: fix close/detach race on streaming teardown

2026-07-22T15:10:58Z

detach() stopped streaming and called uvideo_vs_close() before destroy_dev(), so a concurrent close() could race the teardown and call uvideo_vs_close() a second time (double usbd_transfer_unsetup), and mtx_destroy() could race a close still holding sc_mtx. sc_streaming was also read without the lock in both paths. Reorder detach() to call destroy_dev() first so all in-flight cdev methods drain before any teardown. Read sc_streaming under sc_mtx in both detach() and the last-close safety net.

uvideo: track streaming ownership per-fd and free buffers on STREAMOFF

2026-07-22T15:10:58Z

The driver shared a single streaming state and buffer pool across all open file descriptors, so a second client (e.g. another browser tab) could disrupt the first: its cleanup STREAMOFF would tear down the active stream, and stale buffers prevented re-acquisition. Add per-fd state via devfs cdevpriv tracking whether this fd started streaming. STREAMOFF and close from a non-streaming fd are no-ops. STREAMOFF from the streaming fd stops the stream and frees the buffers so that a new fd can re-acquire the camera. DQBUF returns EPIPE immediately when buffers are freed instead of waiting for a timeout.

uvideo: bounds-check frame interval reads against bLength

2026-07-22T15:10:57Z

Frame interval data is read from device-supplied frame descriptors whose bLength may be shorter than the number of intervals declared by bFrameIntervalType. The continuous branch of uvideo_enum_fivals() read three intervals unconditionally, and the discrete branch checked the pointer but not the four bytes that UGETDW() reads, so a short or malformed descriptor could read past bLength and leak adjacent kernel memory to userspace. uvideo_vs_parse_desc_frame_max_rate() had the same class of off-by-up-to-three-bytes read. Compute the available bytes from bLength and validate before each read. Reported by: emaste

uvideo: lock the mmap queue and read path

2026-07-22T15:10:57Z

qbuf(), dqbuf() and read() manipulated sc_mmap_q / sc_mmap_cur / sc_frames_ready without sc_mtx, racing with the USB transfer callbacks (producer) that run under the mutex. This could corrupt the queue or trigger use-after-free. Take sc_mtx around qbuf(), use mtx_sleep() and protect the queue operations in dqbuf(), and use mtx_sleep() with a snapshot of sc_fsize in read(). Also reject S_FMT and S_PARM with EBUSY while streaming: both re-negotiate the probe/commit controls with the device, which disrupts the active USB transfers (a second client opening the device would otherwise freeze the first one's stream).