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).
No comments yet.