Summary

cs4281_rate_to_rv() executes v = 1536000 / rate with no local zero-check on the user-influenced rate. A zero sample rate would trap a divide-by-zero in kernel mode and panic the system (local DoS).

The PCM core currently prevents this: chn_setparam (channel.c:1974) rejects speed < 1 and the vchan path clamps bestspeed (channel.c:2420-2421), and cs4281_pci_resume passes a stored nonzero spd. So today the value reaching the driver is always >= DSP_DEFAULT_SPEED (8000) / caps minspeed (6024).

The defect is latent: a kernel driver that trusts a framework invariant to avoid a divide-by-zero is fragile, and any future caller (or a vchan/feeder change) that bypasses chn_setparam would turn this into a reachable local panic.

Root cause

cs4281_rate_to_rv (cs4281.c:209-221) loops the fixed rate table, and on miss falls through to:

v = 1536000 / rate;     /* cs4281.c:218 — no zero guard */

rate is the u_int32_t speed argument threaded in from cs4281chan_setspeed (cs4281.c:369-383, called as the channel_setspeed KOBJ method) and ultimately from CHANNEL_SETSPEED (channel.c:1985,2431,2452).

cs4281_rv_to_rate (cs4281.c:223-231) has a symmetric latent issue: r = 1536000 / rv at :229 would trap if rv == 0, but rv == 0 always takes the table branch (rv < CS4281_NUM_RATES → cs4281_rates[0]), so it is safe in practice.

cs4281_rate_to_rv is the only one with a live zero-divide code path.

Threat model

Local unprivileged user with access to the audio device (default devfs perms, or any user in the audio group) setting a sample rate of 0.

Impact: deterministic kernel divide-by-zero trap → system panic → local denial of service.

Currently NOT reachable because the PCM core's chn_setparam (channel.c:1974 if (speed < 1 ...) return EINVAL;) and the vchan bestspeed clamp (channel.c:2420-2421) guarantee speed >= 1 before CHANNEL_SETSPEED dispatches here, and cs4281_pci_resume only passes previously-stored nonzero speeds.

Reported as Info because the bug is real but the trigger is presently framework-blocked; it becomes a real Medium-DoS the moment any path bypasses chn_setparam.

PoC

Cannot be reproduced on a stock DragonFlyBSD kernel today because chn_setparam (sys/dev/sound/pcm/channel.c:1974) rejects speed < 1 before the driver is reached.

A PoC that proves the latent defect by calling the function directly:

/* trigger.c - proof that cs4281_rate_to_rv traps on rate==0 */
#include <sound/pci/cs4281.h>   /* for the function if exported, or link a kld */
/* In a kernel module: */
cs4281_rate_to_rv(0);   /* divides 1536000/0 -> deterministic kernel trap/panic */

Build: put in a kld module, make in a module tree referencing the cs4281 source, kldload ./trigger.kld. Expected: immediate divide-by-zero trap → kernel panic trap division by zero.

On stock userland the ioctl path SNDCTL_DSP_SPEED(fd,0) / AOSSPEED 0 is rejected at channel.c:1974 and never reaches the driver, so a userspace PoC will NOT reproduce it — this is exactly why the finding is Info/speculative rather than Medium.

Recommended fix

Add a local zero-guard in the driver so it does not depend on the framework invariant. Defense in depth; behavior unchanged for all valid rates.

--- a/sys/dev/sound/pci/cs4281.c
+++ b/sys/dev/sound/pci/cs4281.c
@@ -214,6 +214,9 @@ cs4281_rate_to_rv(u_int32_t rate)
     for (v = 0; v < CS4281_NUM_RATES; v++) {
    if (rate == cs4281_rates[v]) return v;
     }
+
+    if (rate == 0)
+       return 5;   /* avoid divide-by-zero; default to 8k */

     v = 1536000 / rate;
     if (v > 255 || v < 32) v = 5; /* default to 8k */

Related findings

Divide-by-zero class:

• DF-1603 (virtio_blk.c blk_size=0)
• DF-1611/1612 (dcn10_hubp.c pixel_clk/htotal)
• DF-1616 (ath_beacon.c lintval==0)
• DF-1648 (freesync.c min_vfreq==0)
• DF-1650 (rs780_dpm.c drm_mode_vrefresh()==0)