mapped_ioctl: heap/stack buffer passed to fo_ioctl uninitialized for IOC_NONE-direction ioctls (kmalloc without M_ZERO, no bzero)
| Field | Value |
|---|---|
| ID | DF-2734 |
| Status | new |
| Severity | Info |
| CVSS 3.1 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N |
| CWE | CWE-908 / CWE-457 |
| File | sys/kern/sys_generic.c |
| Lines | 674-697 |
| Area | kern |
| Confidence | likely |
| Discovered | 2026-08-30 |
| Pass | 2 (GLM 5.3 second pass) |
| Bucket | kernleak |
| Reported | pending |
| Known CVE | none |
| CVE match | novel |
Summary
For a hand-crafted ioctl command with direction bits == 0 and size>0 (up to IOCPARM_MAX=8191), the buffer is kmalloc'd without M_ZERO and none of the fill branches apply (copyin requires IOC_IN, bzero requires IOC_OUT) — uninitialized kernel heap is handed to fo_ioctl. For IOC_VOID commands with size>0 the 128-byte stack buffer likewise only has its first 8 bytes written. No direct userland leak through this path (the generic copyout also requires IOC_OUT); a driver would have to accept such a com and copy out itself (none found — drivers switch on exact com values). Defense-in-depth hardening.
Recommended fix
Zero the buffer unconditionally after allocation (M_WAITOK|M_ZERO
at :675 and bzero on the stack path, or extend the :691 bzero to run
when !(com & IOC_IN)).
Timeline
- 2026-08-30 Discovered during pass-2 audit of sys_generic.c (GLM 5.3).
No comments yet.