FreeBSD 14.5-RC1 has a sound ioctl UAF and a hardware counter that ignored your credentials

FreeBSD 14.5-RC1 landed August 29 with three security fixes in tow. One is a routine OpenSSL update. Two are not routine. The HWPMC one especially deserves a minute.

The sound ioctl use-after-free

SNDCTL_DSP_SYNCSTART is an ioctl for synchronizing DSP audio streams. Somebody found a use-after-free in the kernel’s handling of it, reachable by local unprivileged users, usable for privilege escalation.

Sound driver code in any kernel is historically a graveyard of accumulated workarounds. It accreted over decades when the design objective was “please make noise come out” and correctness audits were left as an exercise for future people who did not exist. A UAF in an audio ioctl is not surprising. What makes it land in an RC1 security fix is that it’s reachable from an unprivileged process and can be used to escalate. That’s the relevant part.

If you have untrusted local users on a FreeBSD host with a sound device, this matters to you. Patch before September 8, or just wait for 14.5-RELEASE and upgrade clean.

The HWPMC credential-transition bug

This one is more interesting.

HWPMC is the FreeBSD Hardware Performance Monitoring Counters subsystem: the interface into the CPU’s PMU (Performance Monitoring Unit). You use it to watch what’s actually happening on the hardware. Instruction counts, cache misses, branch mispredictions, TLB pressure. It’s how you find out your hot path is spending 40% of its cycles on L2 cache misses instead of doing real work. Brendan Gregg has built a career on this stuff. It’s useful.

The bug: when a process being monitored executes a setuid or setgid binary, its credentials change. The new credentials are privileged. The HWPMC driver was not detaching the monitor session on this transition. The unprivileged user who started the monitoring session kept their handle open and could continue reading performance counters on what had just become a root-owned process.

Performance counter data is not memory. You cannot read secrets out of it directly. But “not memory” does not mean “not useful to an attacker.”

PMU data leaks information about what the CPU is doing. Cache hit/miss ratios and instruction counts correlate with code paths. Timing side-channels constructed from PMU data have been used to infer private key bits. If you have a monitoring handle on a setuid binary that is doing something sensitive, you are learning the shape of what it is doing, not just its existence. Whether that’s exploitable in your specific scenario depends on what the process is doing, but “unprivileged user gets sustained PMU visibility into a root process” is not a configuration you want to be in.

The fix is correct and should have been there from the start: HWPMC now detaches properly when a monitored process undergoes a credential transition during exec. The kernel checks, the session dies, you lose your monitoring handle. This is how exec-on-setuid has to work for anything touching process visibility.

Stevens and Rago walk through the exec/credential mechanics in detail in APUE (see /go/book-apue/ if you want to understand exactly what the kernel does to process credentials at exec time). It is one of those sections that aged well.

The OpenSSL update

FreeBSD pulled in the latest upstream OpenSSL fixes. Multiple CVEs handled in one shot by updating to current. No specific names in the RC1 announcement, which is fine. Pulling the upstream fix is the right approach. Distro-specific backport diffing for OpenSSL CVEs is a waste of everyone’s time when the upstream fix exists.

September 8

FreeBSD 14.5-RELEASE is scheduled for September 8. RC1 is close to clean: the security fixes are the headline, not a long list of regressions. If you are running FreeBSD 14-STABLE, get your upgrade path sorted now. Standard drill: freebsd-update fetch && freebsd-update install, reboot, confirm.

If you are still on 13.x, that is a separate conversation and it should not be a long one.

---

See also: OpenSSH’s post-quantum key exchange default and the enterprise meltdown it caused for the adjacent cryptography maintenance story, and Landlock: unprivileged sandboxing without writing a single kernel module if the HWPMC credential story made you think about what visibility untrusted local processes have on your system generally.