NTP PLL discipline state is mutated by hardclock/pps interrupt paths with no lock excluded from sys_ntp_adjtime's ntp_lock — interleaved PLL transitions
| Field | Value |
|---|---|
| ID | DF-2724 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N |
| CWE | CWE-362 Improper Synchronization |
| File | sys/kern/kern_clock.c |
| Lines | 749-751 (outside ntp_spin released at :714), 1802 |
| Area | kern |
| Confidence | likely |
| Discovered | 2026-08-30 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
hardclock() on cpu0 calls ntp_update_second() AFTER releasing ntp_spin, and pps_event() calls hardpps() from device-interrupt context with no lock at all. Meanwhile sys_ntp_adjtime() serializes its PLL updates with lockmgr ntp_lock + crit_enter — a lock neither interrupt path takes, and a crit section that does not exclude interrupts on other CPUs. Consequently time_state/time_status multi-field transitions, time_offset/time_adj/time_freq updates, hardupdate()'s estimates and hardpps()'s pps_tf[]/pps_freq can interleave arbitrarily. Bounded to clock correctness: on supported platforms (pc64/vkernel64 only) every PLL variable load/store is atomic, all steady-state magnitudes stay clamped, per-tick basetime adjustments are normalized; worst realistic outcome is a transient clock error of order ~0.5s during concurrent root-driven ntp_adjtime/hardpps activity. Every racing writer is already privileged or requires PPS hardware (the unprivileged-kernel-consumer route is exactly known DF-0022). Historical 64-bit tearing was only possible on the removed i386 platform.
Recommended fix
Extend ntp_spin over the ntp_update_second() call at :749-751, and take ntp_spin in hardpps() (or convert sys_ntp_adjtime to ntp_spin) so all PLL-state writers share one lock:
--- a/sys/kern/kern_clock.c
+++ b/sys/kern/kern_clock.c
@@ -746,8 +746,10 @@ hardclock(systimer_t info, int in_ipi, struct intrframe *frame)
* Apply leap second (ntp_adjtime() API), calculate a new
* nsec_adj field. ntp_update_second() returns nsec_adj
* as a per-second value but we need it as a per-tick value.
*/
+ spin_lock(&ntp_spin);
leap = ntp_update_second(time_second, &nsec_adj);
nsec_adj /= hz;
+ spin_unlock(&ntp_spin);
nbt->tv_sec += leap;
Timeline
- 2026-08-30 Discovered during pass-2 audit of kern_clock.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2724 · 7 files| File | Type | Description | Size | |
|---|---|---|---|---|
| VERDICT.md | — | 1.9 KB | ↓ raw | |
| README.md | — | 252 B | ↓ raw | |
| build.sh | — | 85 B | view raw | |
| run.sh | — | 49 B | view raw | |
| env.txt | — | 314 B | view raw | |
| manifest.json | — | 614 B | view raw | |
| verdict.json | — | 2.1 KB | view raw |
DF-2724 evidence pack
- finding: sys/kern/kern_clock.c (749, 1609-1676, 1802)
- verdict: reproduced (likely) - see VERDICT.md
- source-only confirmation (no runtime PoC)
- reproduce: build.sh / run.sh
- fix.diff: documented recommendation (no diff)
DF-2724 - Verification Verdict
Status: reproduced Impact: none (hardening) Confidence: likely
Mechanism
The NTP PLL discipline variables (time_state, time_status, nsec_adj, hardpps-driven pps fields) are mutated by the hardclock/pps interrupt paths with no synchronization at all - kern_ntptime.c guards sys_ntp_adjtime/sys_ntptime with ntp_lock (kern_ntptime.c:155,308-411), but the clock paths that mutate the SAME state take nothing, so interleaved PLL transitions are possible.
Verdict
source-confirmed (no runtime PoC; deterministic code trace of the cited path:line in the read-only sys/ tree). Code-certain by inspection (grep: no ntp_lock anywhere in kern_clock.c). A real fix needs lock-free/atomic redesign or moving the discipline under a token that hardclock can take from interrupt context - lockmgr(9) cannot be used there - so this pack carries a documented recommendation rather than a risky one-liner. Impact ceiling: transient timekeeping glitches, not memory safety.
Threat / reachability
Unsynchronized NTP state machine transitions under concurrent adjtime/PPS events.
Privilege escalation assessment
n/a (hardening)
Fix
Documented recommendation (no fix.diff): serialize NTP PLL transitions with an lwkt token (interrupt-safe) instead of the current unsynchronized mutation; upstream FreeBSD shares this exposure.
Kernel references
Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.
(No fix.diff for this item: documented recommendation only - see Fix above.)
Fix verification
not_testableNo fix.diff (documented recommendation in VERDICT.md): Documented recommendation (no fix.diff): serialize NTP PLL transitions with an lwkt token (interrupt-safe) instead of the current unsynchronized mutation; upstream FreeBSD shares this exposure.
n/a (recommendation item)
Confirmed kernel references
Detail
Exploit chain
no escalation path (Info-tier hardening; see VERDICT.md)
Evidence (decisive lines)
VERDICT.md mechanism/verdict sections; fix.diff
PoC changes
none (source-only confirmation for this Info-tier item)
Verified recommended fix
Documented recommendation (no fix.diff): serialize NTP PLL transitions with an lwkt token (interrupt-safe) instead of the current unsynchronized mutation; upstream FreeBSD shares this exposure.
Verdict
source-confirmed (no runtime PoC; deterministic code trace of the cited path:line in the read-only sys/ tree). Code-certain by inspection (grep: no ntp_lock anywhere in kern_clock.c). A real fix needs lock-free/atomic redesign or moving the discipline under a token that hardclock can take from interrupt context - lockmgr(9) cannot be used there - so this pack carries a documented recommendation rather than a risky one-liner. Impact ceiling: transient timekeeping glitches, not memory safety.
No comments yet.