Unsynchronized data race on desc->total_objects (statistics-only, no security impact)

Summary

objcache_set_cluster_limit updates depot->unallocated_objects under depot->spin (:368) but writes oc->desc->total_objects += delta outside the lock (:373). total_objects is read by sysctl_ocstats (:971) under a different lock (objcachelist_spin), and two concurrent set_cluster_limit callers also race on the field with no mutual lock — a genuine unsynchronized read-modify-write (UB in C). On x86 the int accesses are atomic so no torn values, but lost updates can drift the displayed oc_limit statistic.

Impact is strictly cosmetic: total_objects gates nothing in the allocator path (only unallocated_objects does, at :508); it is only emitted via sysctl kern.objcache.stats. No memory-safety, privilege, or DoS consequence.

Recommended fix

--- a/sys/kern/kern_objcache.c
+++ b/sys/kern/kern_objcache.c
@@ -367,6 +367,7 @@
        delta = cluster_limit - depot->cluster_limit;
        depot->unallocated_objects += delta;
        depot->cluster_limit = cluster_limit;
+       oc->desc->total_objects += delta;
        spin_unlock(&depot->spin);
        wakeup(depot);
-
-       oc->desc->total_objects += delta;

(Move the total_objects update inside the depot->spin critical section.)

Timeline

• 2026-06-30 Discovered during automated file-by-file audit of sys/kern/kern_objcache.c.
• pending Reported to DragonFlyBSD security contact.