sockbuf drop/flush family ignores M_SOLOCKED — latent use-after-free window against sorecvtcp's token-released uiomove loop
| Field | Value |
|---|---|
| ID | DF-2893 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:N |
| CWE | CWE-667 Improper Locking |
| File | sys/kern/uipc_sockbuf.c |
| Lines | 473-535, 451-465, 548-578 (honored only at :376) |
| Area | kern |
| Confidence | speculative |
| Discovered 2026-09-02 | |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | memcorrupt |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
sorecvtcp marks a window of so_rcv mbufs M_SOLOCKED, releases the ssb token, and uiomoves directly out of them. The design contract is that every concurrent mutator honors the flag; but only sbcompress checks it. sbdrop, sbdroprecord, sbflush and sbunlinkmbuf will trim/unlink/free M_SOLOCKED mbufs without any check — a concurrent flush during the unlocked uiomove loop would yield a kernel UAF read (freed mbuf data copied to userspace) and a freed-pointer chase. Today latent: for TCP the sole so_rcv mutators during a live recv are sbappendstream/sbcompress, the soclose-triggered sbflush is excluded by the recv syscall's file-reference hold, RST teardown does not flush so_rcv; the only in-tree so_rcv dropper on a protocol callback (sco_input) is bluetooth-hw-gated. Defense-in-depth: one new protocol or a sorecvtcp conversion turns this into a direct UAF. Fix: KKASSERT/skip M_SOLOCKED in the drop/flush family (row diff).
Timeline
- 2026-09-02 Discovered during pass-2 audit of uipc_sockbuf.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2893 · 8 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 677 B | ↓ raw | |
| VERDICT.md | — | 1.8 KB | ↓ raw | |
| build.sh | — | 56 B | view raw | |
| env.txt | — | 509 B | view raw | |
| manifest.json | — | 555 B | view raw | |
| run.sh | — | 87 B | view raw | |
| sourcenote.txt | — | 651 B | view raw | |
| verdict.json | — | 2.6 KB | view raw |
DF-2893 — sockbuf drop family ignores M_SOLOCKED (Info-tier hardening verification)
What
sockbuf drop family ignores M_SOLOCKED
Build
(source confirmation only)
Run
(source confirmation only)
Expected
baseline (stock kernel): see verdict below fix kernel (all-41-fixes build): the bad behavior is gone
Files
README.md VERDICT.md build.sh env.txt fix.diff manifest.json run.sh sourcenote.txt verdict.json
Shared harness: h41.c (combined KLD, sysctl debug.h41.cmd=N driven).
Full batch context: the fix kernel contains all 41 hardening fixes of
this batch compiled together (build RC=0) and passed the complete A/B
suite plus a clean reboot.
DF-2893 — VERDICT
status: reproduced | reproduced: 1 | impact: none | confidence: certain
Line-accurate confirmation (no live in-tree trigger - TCP's only concurrent so_rcv mutators are append/compress; soclose sbflush is fp-ref-excluded; the sole live dropper sco_input is bt-hw-gated): sorecvtcp marks mbufs M_SOLOCKED and uiomoves directly out of them with the ssb token released (uipc_socket.c:1740-1778); the only code honoring the flag is sbcompress (uipc_sockbuf.c:376). sbdrop (:473-508), sbdroprecord (:517-535), sbflush (:451-465) and sbunlinkmbuf (:548-578) trim/unlink/free M_SOLOCKED mbufs unchecked - a concurrent flush during the unlocked uiomove would be a kernel UAF read of freed mbuf data to userspace. FIX VALIDATION WAS DECISIVE: the finding's suggested shape (KKASSERT M_SOLOCKED==0 in the drop family) PANICKED the fix kernel at boot - sorecvtcp itself legitimately unlinks its own still-flagged mbufs after consuming them (uipc_socket.c:1832-1841), so the flag cannot be asserted at these chokepoints without owner tracking. The assert was reverted; the recorded recommendation is owner-aware checks (record the locking thread in the mbuf or skip-and-requeue semantics).
Fix-validation boot panic (v1)
The drop-family KKASSERT fix panicked the fix kernel at boot: panic: assertion "(m->m_flags & M_SOLOCKED) == 0" failed in sbunlinkmbuf at uipc_sockbuf.c:555 sorecvtcp() -> soo_read() -> kern_preadv() sorecvtcp itself legitimately unlinks its own still-flagged mbufs after consuming them (uipc_socket.c:1832-1841). The suggested fix shape (plain asserts in the drop family) is wrong; owner tracking is required. Assert reverted; recommendation recorded.
Baseline vs fix kernel
baseline: see verdict above / run log fix: behavior changed as designed (see verdict)
Fix verification
not_testableFix-v1 (drop-family KKASSERTs) false-positives on the legitimate owner path and panics at boot - reverted. A correct fix needs M_SOLOCKED ownership tracking; documented as the revised recommendation rather than shipped.
Confirmed kernel references
Detail
Evidence (decisive lines)
sourcenote.txt: checker-vs-dropper map; VERDICT.md documents the boot panic of fix-v1 (sbunlinkmbuf assert via sorecvtcp) proving the assert approach wrong
PoC changes
none
Verified recommended fix
Track the M_SOLOCKED owner thread (or skip-and-requeue); plain asserts at sbdrop/sbflush are wrong (boot-validated)
Verdict
Line-accurate confirmation (no live in-tree trigger - TCPs only concurrent so_rcv mutators are append/compress; soclose sbflush is fp-ref-excluded; the sole live dropper sco_input is bt-hw-gated): sorecvtcp marks mbufs M_SOLOCKED and uiomoves directly out of them with the ssb token released (uipc_socket.c:1740-1778); the only code honoring the flag is sbcompress (uipc_sockbuf.c:376). sbdrop (:473-508), sbdroprecord (:517-535), sbflush (:451-465) and sbunlinkmbuf (:548-578) trim/unlink/free M_SOLOCKED mbufs unchecked - a concurrent flush during the unlocked uiomove would be a kernel UAF read of freed mbuf data to userspace. FIX VALIDATION WAS DECISIVE: the findings suggested shape (KKASSERT M_SOLOCKED==0 in the drop family) PANICKED the fix kernel at boot - sorecvtcp itself legitimately unlinks its own still-flagged mbufs after consuming them (uipc_socket.c:1832-1841), so the flag cannot be asserted at these chokepoints without owner tracking. The assert was reverted; the recorded recommendation is owner-aware checks (record the locking thread in the mbuf or skip-and-requeue semantics).
No comments yet.