Unchecked mbuf allocations in mb_init/mb_reserve/mb_put_mem/md_init — NULL-pointer kernel panic under allocation failure
| Field | Value |
|---|---|
| ID | DF-2906 |
| Status | new |
| Severity | Low |
| CVSS 3.1 | CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H |
| CWE | CWE-476 NULL Pointer Dereference |
| File | sys/kern/libmchain/subr_mchain.c |
| Lines | 75-77, 131-135, 206-210, 308-310 |
| Area | libmchain (legacy smb consumer) |
| Confidence | certain |
| Discovered | 2026-09-02 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | legacy |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
mb_init (:75-77) and md_init (:308-310) immediately dereference m_gethdr(M_WAITOK) results; mb_reserve (:131-135) links and writes m_get(M_WAITOK) without a check; mb_put_mem (:206-210) assigns m_getc(M_WAITOK) and then dereferences m->m_next via M_TRAILINGSPACE(m) when it returns NULL. In DragonFly these M_WAITOK allocations genuinely can fail: m_get retries once after reclaim then gives up counting m_drops (uipc_mbuf.c:1015-1034), and objcache_get returns NULL on back-end allocator/ctor failure even with M_WAITOK (kern_objcache.c: 514-537; the blocking path only covers cluster-limit exhaustion). Under real VM pressure an active smbfs session panics the kernel instead of returning ENOBUFS. FreeBSD stable/12 carries the same pattern; upstream deleted netsmb instead of fixing. Fix: check every allocation.
Timeline
- 2026-09-02 Discovered during pass-2 audit of subr_mchain.c (GLM 5.3).
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2906 · 6 files| File | Type | Description | Size | |
|---|---|---|---|---|
| README.md | — | 557 B | ↓ raw | |
| VERDICT.md | — | 2.0 KB | ↓ raw | |
| env.txt | — | 401 B | view raw | |
| fix.diff | — | 1.7 KB | view raw | |
| manifest.json | — | 551 B | view raw | |
| verdict.json | — | 2.0 KB | view raw |
DF-2906 PoC evidence pack
What
Unchecked mbuf allocations in mb_init/mb_reserve/mb_put_mem/md_init (mchain).
Build
(none)
Run
(none)
Expected
static confirmation of four unchecked M_WAITOK allocation sites
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 All logs are full untrimmed captures unless noted. fix.diff is the git-apply-able verified fix (authored after verification; never applied to the audit tree).
DF-2906 - verification verdict
Status: not_reproduced | reproduced: 0 | impact: panic | confidence: certain
All four unchecked allocation sites confirmed line-accurate in the actual kernel text (the mchain library ships only in smbfs.ko on this system - itself a reachability datapoint: an active SMB session is the context). mb_init/md_init dereference m_gethdr(M_WAITOK) immediately; mb_reserve links m_get(M_WAITOK) and dereferences it; mb_put_mem assigns m_getc(M_WAITOK) into m->m_next then computes M_TRAILINGSPACE(m) on NULL. Injecting objcache back-end failure for M_WAITOK mbuf allocations on a live INVARIANTS guest is not honestly constructible without a fault-injection framework, so the panic form was not forced; the sibling DF-2907 defects in the same file WERE exercised live (see DF-2907, including the m_copym KASSERT panic through md_get_mbuf). Full fix (every allocation checked) compiled into the fix-all kernel and exercised via the md_* paths.
Evidence pointers
static: subr_mchain.c:75-77,131-135,206-210,308-310; runtime paths exercised under DF-2907
Kernel references
- sys/kern/libmchain/subr_mchain.c:75
- sys/kern/libmchain/subr_mchain.c:131
- sys/kern/libmchain/subr_mchain.c:206
- sys/kern/libmchain/subr_mchain.c:308
PoC changes vs the filing sketch
allocation-failure injection infeasible; relied on line-accurate confirmation + sibling live run
Fix
recommendation: check every m_get/m_gethdr/m_getc result
fix status: not_testable
compile-validated in fix-all kernel; md_* paths of the same file A/B validated under DF-2907
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:04 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
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.
Fix verification
not_testablecompile-validated in fix-all kernel; md_* paths of the same file A/B validated under DF-2907
Confirmed kernel references
Detail
Evidence (decisive lines)
static: subr_mchain.c:75-77,131-135,206-210,308-310; runtime paths exercised under DF-2907
PoC changes
allocation-failure injection infeasible; relied on line-accurate confirmation + sibling live run
Verified recommended fix
check every m_get/m_gethdr/m_getc result
Verdict
All four unchecked allocation sites confirmed line-accurate in the actual kernel text (the mchain library ships only in smbfs.ko on this system - itself a reachability datapoint: an active SMB session is the context). mb_init/md_init dereference m_gethdr(M_WAITOK) immediately; mb_reserve links m_get(M_WAITOK) and dereferences it; mb_put_mem assigns m_getc(M_WAITOK) into m->m_next then computes M_TRAILINGSPACE(m) on NULL. Injecting objcache back-end failure for M_WAITOK mbuf allocations on a live INVARIANTS guest is not honestly constructible without a fault-injection framework, so the panic form was not forced; the sibling DF-2907 defects in the same file WERE exercised live (see DF-2907, including the m_copym KASSERT panic through md_get_mbuf). Full fix (every allocation checked) compiled into the fix-all kernel and exercised via the md_* paths.
No comments yet.