kqsort_r recurses without depth bound: latent stack-exhaustion DoS (sibling of DF-2245 via shared qsort.c body)

Summary

qsort_r.c is 8-line shim: #define I_AM_KQSORT_R then #include libkern/qsort.c. All effective code audited in qsort.c. kqsort_r body performs genuine (non-tail) recursive call at qsort.c:175 on left partition. Worst-case recursion depth O(n): adversary forces pivot to partition maximum left region holds ~n-1 elements at every level blows kernel stack. Tail-call-eliminated goto loop at qsort.c:179-184 only protects second (right-partition) call not this one. swap_cnt==0 insertion-sort escape does not trigger killer input still causes swaps during partitioning. Same root cause as DF-2245 (qsort.c Medium) shared body. Today ZERO in-tree callers of kqsort_r (verified grep sys/) so no current concrete attack path bug is latent. Impact if kernel subsystem or privileged KLD later calls kqsort_r on attacker-influenced data with n above few hundred to ~10^4 is kernel-stack exhaustion (8-16KiB amd64 stack ~96-160 byte frames) double fault/panic local DoS. Loadable-module callers require CAP_KLD_LOAD root. Fix: always recurse on smaller partition iterate on larger bounds depth O(log n) apply in shared qsort.c closes both DF-2245 and this finding.