socket_wait() leaks one file descriptor into the caller's fd table on every call (and on its error path)
| Field | Value |
|---|---|
| ID | DF-2735 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L |
| CWE | CWE-401 / CWE-772 |
| File | sys/kern/sys_generic.c |
| Lines | 1699-1727 |
| Area | kern |
| Confidence | certain |
| Discovered | 2026-08-30 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | base:kern |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
socket_wait() does falloc+fsetfd (which publishes a new fd holding its own reference) but never closes/uninstalls it: on the kqueue_register error path it fdrop()s only the caller's reference (fd remains), and on the success path it swaps fp->f_ops to badfileops and fdrop()s — the fd stays permanently installed in curproc's table, unknown to the caller. No UAF (fsetfd takes its own reference), purely an fd leak: each call permanently consumes one descriptor until process exit. Only in-tree caller is netproto/smb/smb_trantcp.c:226 (legacy bucket) — repeated SMB transactions exhaust the caller's fd limit.
Recommended fix
Track the reserved fd and uninstall it before returning (funsetfd on the error path; pass the fd back or close it on completion).
Timeline
- 2026-08-30 Discovered during pass-2 audit of sys_generic.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2735 · 3 files| File | Type | Description | Size | |
|---|---|---|---|---|
| v26harness.c | — | 14.3 KB | view raw | |
| run.log | — | 165 B | view raw | |
| fix.diff | — | 566 B | view raw |
Fix verification
not_testableFix v1 (fsetfd(NULL, fd)) was REFUTED by A/B on the patched kernel: it tripped panic: assertion fdp->fd_files[fd].reserved != 0 failed in fsetfd_locked because fsetfd(NULL) only un-reserves never-installed slots, while socket_waits fd was already installed. Fix v2 rewrites both exit paths to the public kern_close(fd) protocol (fp->f_ops = &badfileops; kern_close(fd); fdrop(fp)) mirroring sys_closes uninstall sequence (kern_descrip.c:1465-1515). v2 is compile-validated with the exact kernel build flags (cc -c ... /usr/src/sys/kern/sys_generic.c -> 0 errors); its full-kernel runtime A/B was blocked by guest I/O degradation following the DF-2880 swap-death test and remains pending on a fresh guest cycle.
v1 A/B panic captured in serial log (fsetfd_locked assertion); v2 single-file compile: CC-RC=0
Confirmed kernel references
Detail
Exploit chain
socket_wait x50 -> fsetfd publishes fd (fhold) -> neither path uninstalls -> +50 fds in caller (3 -> 53)
Evidence (decisive lines)
v26harness.c t2 (cmd=2); df2735_mod.log: fds before=3 after=53 LEAKED=50
PoC changes
initial ts={0,2ns} made kern_kevent sleep forever (0 ticks = infinite tsleep); ts=10ms per call completes 50 calls in ~0.5s
Verified recommended fix
--- sys/kern/sys_generic.c 2026-06-29 12:51:19.000000000 +0000
Verdict
Reproduced via kernel harness calling the exported socket_wait() (sys/kern/sys_generic.c:1690-1728) 50 times in one process context: the processs installed-fd count went from 3 to 53 - exactly one leaked descriptor per call. falloc+fsetfd publishes an fd holding its own reference (fsetfd_locked does fhold, sys/kern/kern_descrip.c:2186-2204) and socket_wait never uninstalls it: the error path fdrop()s only the caller reference, and the success path swaps f_ops to badfileops and fdrop()s - the fd stays installed forever, unknown to the caller. Sole in-tree caller is legacy smb_trantcp.c:226; every SMB transaction burns one fd until the process exits. No UAF; fd-exhaustion DoS for the caller only.
No comments yet.