• File: sys/dev/acpica/acpi_timer.c
• Lines: 310–324 (handler), kern_cputimer.c:187-194 (unguarded divide)
• Severity: Low
• CVSS 3.1: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U:C:N/I:N/A:H
• CWE: CWE-369 Divide By Zero
• Confidence: certain
• Status: new

Summary

acpi_timer_sysctl_freq validates only the current frequency (acpi_cputimer.freq == 0 → EOPNOTSUPP) but never validates the new user-supplied freq before passing it to cputimer_set_frequency.

A root user writing 0 to machdep.acpi_timer_freq triggers (1000000LL << 32) / 0 in kern_cputimer.c:190, an immediate divide-by-zero fault that panics the kernel.

Root cause

In sys/dev/acpica/acpi_timer.c:310-324 the handler is:

if (acpi_cputimer.freq == 0)
    return (EOPNOTSUPP);
freq = acpi_cputimer.freq;
error = sysctl_handle_int(oidp, &freq, 0, req);
if (error == 0 && req->newptr != NULL)
    cputimer_set_frequency(&acpi_cputimer, freq);

The guard at line 316 only rejects the call when the existing freq is 0. After sysctl_handle_int returns (kern_sysctl.c:1009-1027 performs NO value validation — it just copies 4 bytes from userspace into &freq), freq holds whatever the caller wrote, including 0.

Line 321 then unconditionally calls cputimer_set_frequency(&acpi_cputimer, freq).

In sys/kern/kern_cputimer.c:187-194:

timer->freq = freq;
timer->freq64_usec = (1000000LL << 32) / freq;
timer->freq64_nsec = (1000000000LL << 32) / freq;

There is no zero guard here either, so freq==0 produces a CPU divide-by-zero exception (#DE) in ring 0 → kernel panic.

SYSCTL_PROC at acpi_timer.c:326-327 is declared CTLTYPE_INT | CTLFLAG_RW with no CTLFLAG_SECURE and no CTLFLAG_ANYBODY, so kern_sysctl.c:1446-1447 enforces SYSCAP_NOSYSCTL_WR — i.e., only uid 0 (or a process granted the sysctl-write capability) can reach this.

The same unguarded divide exists for any future caller of cputimer_set_frequency (it is an exported symbol, systimer.h:166); the i8254 caller at clock.c:964 happens to feed it a calibrated, non-zero value, so it is not currently a second instance.

Threat model

Attacker position: any process holding uid 0 (root) OR a process granted the SYSCAP_NOSYSCTL_WR capability via DragonFly's caps(4) mechanism (caps_priv_check at kern_sysctl.c:1447).

A delegated semi-privileged subsystem that has been granted sysctl-write but not full root could abuse this.

Impact: unconditional, single-syscall kernel panic (denial of service); no memory corruption, no info leak, no privilege escalation.

Pre-conditions:

• ACPI timer driver attached (default on any ACPI x86 system),
• securelevel <= 0 (sysctl is not flagged CTLFLAG_SECURE, so even at securelevel>0 it would still be writable as long as the WR bit is set and caps permit).

Reproducible 100% of the time on the first attempt.

Proof of concept

From a root shell

sysctl machdep.acpi_timer_freq=0

Expected: immediate kernel panic with a divide-by-zero fault (#DE / T_DIVIDE trap), system halts or reboots depending on hw.panic_reboot.

Equivalent C

/* setfreq0.c -- build: cc -o setfreq0 setfreq0.c
 * Run as uid 0; expects kernel panic in handler.
 */
#include <sys/types.h>
#include <sys/sysctl.h>
#include <stdio.h>

int main(void) {
    unsigned int freq = 0;
    size_t len = sizeof(freq);
    int r = sysctlbyname("machdep.acpi_timer_freq", NULL, NULL, &freq, len);
    if (r != 0) { perror("sysctl"); return 1; }
    /* not reached on success: kernel panics inside the handler */
    return 0;
}

Success criterion: dmesg/panic.txt contains "Fatal trap instruction fault" / "divide by zero" / "trap 0" in ring 0 inside cputimer_set_frequency.

No elevated uid needed beyond what root already has; the value of the PoC is proving the missing input validation path and the unguarded library-level divide.

Recommended fix

Reject the zero value at the sysctl handler (the cheapest, most localized fix), and additionally guard cputimer_set_frequency itself as defense-in-depth since it is an exported symbol.

In sys/dev/acpica/acpi_timer.c, after sysctl_handle_int returns and before invoking cputimer_set_frequency:

--- a/sys/dev/acpica/acpi_timer.c
+++ b/sys/dev/acpica/acpi_timer.c
@@ -316,8 +316,12 @@ acpi_timer_sysctl_freq(SYSCTL_HANDLER_ARGS)

     if (acpi_cputimer.freq == 0)
    return (EOPNOTSUPP);
-    freq = acpi_cputimer.freq;
+    freq = (u_int)acpi_cputimer.freq;
     error = sysctl_handle_int(oidp, &freq, 0, req);
-    if (error == 0 && req->newptr != NULL)
-   cputimer_set_frequency(&acpi_cputimer, freq);
+    if (error == 0 && req->newptr != NULL) {
+   if (freq == 0)
+       error = EINVAL;
+   else
+       cputimer_set_frequency(&acpi_cputimer, freq);
+    }

     return (error);
 }

And in sys/kern/kern_cputimer.c, harden the primitive itself:

--- a/sys/kern/kern_cputimer.c
+++ b/sys/kern/kern_cputimer.c
@@ -186,6 +186,8 @@ void
 cputimer_set_frequency(struct cputimer *timer, sysclock_t freq)
 {
+    if (freq == 0)
+   panic("cputimer_set_frequency: zero frequency for %s", timer->name);
     timer->freq = freq;
     timer->freq64_usec = (1000000LL << 32) / freq;
     timer->freq64_nsec = (1000000000LL << 32) / freq;

Returning EINVAL from the sysctl handler preserves the existing ABI (no behavior change for any non-zero frequency) while closing the divide-by-zero. The kern_cputimer.c panic makes any future buggy caller fail loudly instead of silently corrupting state.

References

• sys/dev/acpica/acpi_timer.c:310-324 — sysctl handler with missing zero-check
• sys/kern/kern_cputimer.c:187-194 — unguarded divide-by-freq in cputimer_set_frequency
• sys/kern/kern_sysctl.c:1446-1447 — SYSCAP_NOSYSCTL_WR privilege gate
• sys/sys/systimer.h:166 — cputimer_set_frequency exported symbol (future callers at risk)