src/sys/dev, branch releng/14.3

vt: Avoid integer overflow in CONS_HISTORY ioctl

2026-06-07T17:48:17Z

Approved by: so Security: FreeBSD-SA-26:34.vt Security: CVE-2026-49416 Reviewed by: markj, vexeduxr Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57250 (cherry picked from commit 0ae946e7223df5ef3f7980af1d774d7f593f6421) (cherry picked from commit deaaddf1d3c4283649945553ad7e3208c8424308) (cherry picked from commit b5a4f4bfbc95d5d5361da708728f7f4a6db2ee60)

sound: Fix software buffer lifetime issues

2026-06-07T17:48:04Z

The channel buffer mapped by dsp_mmap_single() may be freed when the device handle is closed, but the mapping persists beyond that, allowing userspace to read or write memory owned by a different consumer. Fix the problem by adding a reference counter to the sound buffer. Define pager ops for the VM object returned by dsp_mmap_single() and use them to manage the extra reference. Add a regression test. Approved by: so Security: FreeBSD-SA-26:27.sound Security: CVE-2026-49417 Reported by: Lexpl0it, 75Acol, Liyw979, Rob1n Reviewed by kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57393

sound: Check for offset overflow in dsp_mmap_single()

2026-06-07T17:23:12Z

Approved by: so Security: FreeBSD-SA-26:27.sound Security: CVE-2026-45258 Reviewed by: markj Sponsored by: The FreeBSD Foundation

netmap: Drain selinfo sleepers in nm_os_selinfo_uninit()

2026-05-19T23:48:36Z

Approved by: so Security: FreeBSD-SA-26:19.file Security: CVE-2026-45251

bnxt: Fix BASE-T, 40G AOC, 1G-CX, autoneg and unknown media lists

2025-09-14T00:24:43Z

This was broken in c63d67e137f3, the early returns prevent building the media lists as expected. The BASE-T parts of the patch were suggested by "cyric@mm.st", while I am adding the additional 40G AOC, 1CX, autoneg and unknown PHY fixes based on code inspection. There may be additional work left here for Broadcom but this is certainly better than the returns. PR: 287395 Reported by: mickael.maillot@gmail.com, cyric@mm.st Tested by: Einar Bjarni Halldórsson Approved by: so Security: FreeBSD-EN-25:17.bnxt (cherry picked from commit 5e6e4f752833acc96f1efc893318d3f6b74b9689) (cherry picked from commit 33f65f12eba10588827a13d232337616f6f4facf)

sound: Terminate stream properly when closing vchans

2025-05-29T22:51:30Z

When a channel is closed, dsp_close() either calls vchan_destroy() on vchans, or chn_abort()/chn_flush() on primary channels. However, the problem with this is that, when closing a vchan, we end up not terminating the stream properly. The call sequence we are interested in is the following: vchan_destroy(vchan) -> chn_kill(vchan) -> chn_trigger(vchan) -> vchan_trigger(vchan) -> chn_notify(parent) Even though chn_notify() contains codepaths which call chn_abort(parent), apparently we do not execute any of those codepaths in this case, so the DMA remains unterminated, hence why we keep seeing the primary channel(s) being interrupted even once the application has exited: root@freebsd:~ # sndctl interrupts dsp0.play.0.interrupts=1139 dsp0.record.0.interrupts=0 root@freebsd:~ # sndctl interrupts dsp0.play.0.interrupts=1277 dsp0.record.0.interrupts=0 root@freebsd:~ # sndctl interrupts dsp0.play.0.interrupts=1394 dsp0.record.0.interrupts=0 The only applications that do not have this issue are those (e.g., mpv) that manually call ioctls which end up calling chn_abort(), like SNDCTL_DSP_HALT, to abort the channel(s) during shutdown. For all other applications that do not manually abort the channel(s), we can confirm that chn_abort()/chn_flush(), or even chn_trigger(PCMTRIG_ABORT) on the parent, doesn't happen during shutdown. root@freebsd:~ # dtrace -n 'fbt::chn_abort:entry,fbt::chn_flush:entry { printf("%s", args[0]->name); stack(); }' dtrace: description 'fbt::chn_abort:entry,fbt::chn_flush:entry ' matched 2 probes dtrace: buffer size lowered to 1m ^C [...] root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]->name); stack(); }' dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe dtrace: buffer size lowered to 1m CPU ID FUNCTION:NAME 0 68037 chn_trigger:entry dsp0.virtual_play.0 sound.ko`chn_kill+0x134 sound.ko`vchan_destroy+0x94 sound.ko`dsp_close+0x39b kernel`devfs_destroy_cdevpriv+0xab kernel`devfs_close_f+0x63 kernel`_fdrop+0x1a kernel`closef+0x1e3 kernel`closefp_impl+0x76 kernel`amd64_syscall+0x151 kernel`0xffffffff8103841b1 To fix this, modify dsp_close() to execute the primary channel case on both primary and virtual channels. While what we really care about are the chn_abort()/chn_flush() calls, it shouldn't hurt to call the rest of the functions on the vchans as well, to avoid complicating things; they get deleted right below, anyway. With the patch applied: root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]->name); stack(); }' dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe dtrace: buffer size lowered to 1m CPU ID FUNCTION:NAME 1 68037 chn_trigger:entry dsp0.virtual_play.0 sound.ko`chn_flush+0x2a sound.ko`dsp_close+0x330 kernel`devfs_destroy_cdevpriv+0xab kernel`devfs_close_f+0x63 kernel`_fdrop+0x1a kernel`closef+0x1e3 kernel`closefp_impl+0x76 kernel`amd64_syscall+0x151 kernel`0xffffffff8103841b 0 68037 chn_trigger:entry dsp0.play.0 sound.ko`chn_notify+0x4ce sound.ko`vchan_trigger+0x105 sound.ko`chn_trigger+0xb4 sound.ko`chn_flush+0x2a sound.ko`dsp_close+0x330 kernel`devfs_destroy_cdevpriv+0xab kernel`devfs_close_f+0x63 kernel`_fdrop+0x1a kernel`closef+0x1e3 kernel`closefp_impl+0x76 kernel`amd64_syscall+0x151 kernel`0xffffffff8103841b Above we can see a chn_trigger(PCMTRIG_ABORT) on the parent (dsp0.play.0), which is coming from the chn_abort() (inlined) in chn_notify(): root@freebsd:~ # dtrace -n 'kinst::chn_abort:entry { stack(); }' dtrace: description 'kinst::chn_abort:entry ' matched 5 probes dtrace: buffer size lowered to 1m CPU ID FUNCTION:NAME 1 72580 chn_notify:1192 sound.ko`0xffffffff8296cab4 sound.ko`vchan_trigger+0x105 sound.ko`chn_trigger+0xb4 sound.ko`chn_flush+0x2a sound.ko`dsp_close+0x330 kernel`devfs_destroy_cdevpriv+0xab kernel`devfs_close_f+0x63 kernel`_fdrop+0x1a kernel`closef+0x1e3 kernel`closefp_impl+0x76 kernel`amd64_syscall+0x151 kernel`0xffffffff8103841b We can also confirm the primary channel(s) are not interrupted anymore: root@freebsd:/mnt/src # sndctl interrupts dsp0.play.0.interrupts=0 dsp0.record.0.interrupts=0 In collaboration with: adrian Tested by: adrian, christos, thj Sponsored by: The FreeBSD Foundation MFC after: 2 days Reviewed by: thj, adrian, emaste Differential Revision: https://reviews.freebsd.org/D50488 (cherry picked from commit f6430bc61df78be070209d52b4452ae9cf4cd015) (cherry picked from commit 0c6aa445ec0c85e7c9653d20562907742569de6f) Approved by: re (cperciva)

snd_hda: Add shutdown method

2025-05-21T23:21:42Z

Power down the device on shutdown similar to what is done in the case of suspend. The device may fail to attach on next boot without this. PR: 286385 Reviewed by: christos, adrian Differential Revision: https://reviews.freebsd.org/D50306 (cherry picked from commit d9900b9ea2b27f7a0c2eda97841b9499e02e3ea7) (cherry picked from commit 77521692f4c71213c5419268657e696532c28325) Approved by: re (cperciva)

sound: Call PCM_RELEASE() if pcm_addchan() fails

2025-05-14T14:23:53Z

Fixes: fd906e47b18f ("sound: Simplify locking during device creation") Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D50337 (cherry picked from commit dbfe79bbe5d5ebe296fbff2d101e0994d7881d0d) (cherry picked from commit 3de66f369c1e8db46ae938d446a72f6ff3493356) Approved by: re (cperciva)

ena: Bump driver version to v2.8.1

2025-05-01T17:51:52Z

Changes since 2.8.0: Bug Fixes: * Fix LLQ normal width misconfiguration * Check for errors when detaching children first, not last Minor Changes: * Remove \n from sysctl description Approved by: cperciva (mentor) Sponsored by: Amazon, Inc. Differential Revision: https://reviews.freebsd.org/D50041 (cherry picked from commit 59b30c1a864ee8a22c2e9912301cb88674f714c9)

ena: Fix misconfiguration when requesting regular LLQ

2025-05-01T17:51:52Z

Patch 0a33c047a443 introduced new values to hw.ena.force_large_llq_header. The default value of 2 means no preference, while 0 and 1 act as the previous false and true respectively, which allowed forcefully setting regular or large LLQ. There are 2 ways to force the driver to select regular LLQ: 1. Setting hw.ena.force_large_llq_header = 0 via sysctl. 2. Turning on ena express, which makes the recommendation by the FW to be regular LLQ. When the device supports large LLQ but the driver is forced to regular LLQ, llq_config->llq_ring_entry_size_value is never initialized and since it is a variable allocated on the stack, it stays garbage. Since this variable is involved in calculating max_entries_in_tx_burst, it could cause the maximum burst size to be zero. This causes the driver to ignore the real maximum burst size of the device, leading to driver resets in devices that have a maximum burst size (Nitro v4 and on. see [1] for more information). In case the garbage value is 0, the calculation of max_entries_in_tx_burst divides by 0 and causes kernel panic. The patch modifies the logic to take into account all use-cases and ensure that the relevant fields are properly initialized. [1]: https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html Fixes: 0a33c047a443 ("ena: Support LLQ entry size recommendation from device") Approved by: cperciva (mentor) Sponsored by: Amazon, Inc. Differential Revision: https://reviews.freebsd.org/D50040 (cherry picked from commit 56c45700f2ae15755358f2da8266247613c564df)