MayteraOS Security Audit (Summary)
What was audited
In early 2026, the MayteraOS kernel underwent a comprehensive internal source-code security review. The audit covered every major subsystem: physical and virtual memory management, the kernel heap allocator, process lifecycle and the scheduler, the ELF loader, the full network stack (Ethernet, ARP, IP, ICMP, UDP, TCP, DHCP), network and storage drivers, the FAT filesystem driver, and the GUI/window manager. Findings were rated on a five-level scale (Critical, High, Medium, Low, Info) based on impact, from remote code execution and privilege escalation down to code-quality observations.
Categories of findings
The audit recorded 35 findings: 7 critical, 9 high, 11 medium, 6 low, and 2 informational. At a high level they fell into six categories:
- Privilege separation. The largest architectural findings concerned user/kernel isolation: at the time of the audit, the kernel still ran on firmware-provided identity-mapped page tables and loaded user programs into kernel memory, so Ring 3 isolation was not yet enforced.
- Memory safety. Integer overflow and underflow risks in size calculations (loader, heap, network handlers), inline heap metadata that could be forged by an overflow, and process stacks allocated without guard pages.
- Untrusted input validation. Insufficient bounds checking on externally supplied data: network packets, hardware-reported lengths and descriptor indices from NICs, crafted executable files, and malformed filesystem structures.
- Concurrency. Scheduler queues and network-stack state that needed stronger locking to be safe on multiprocessor systems.
- Exploit mitigations. Defense-in-depth features that did not yet exist, such as address-space layout randomization and stack canaries.
- Process hygiene. A small number of findings about development practices rather than kernel code, such as credentials appearing in internal documentation; these were flagged for immediate removal.
What was fixed
Work completed alongside the audit included a kernel capability system for controlling access to resources. Its design: capability tokens signed with HMAC-SHA256 using a key generated at boot from the hardware random number generator (the key never leaves kernel memory), atomic validation with expiry checked on every use to prevent time-of-check/time-of-use races, automatic cleanup of a process's capabilities on exit, and an in-kernel audit trail of capability operations. The audit itself confirmed several good practices already in place, such as consistent checking of allocation failures across the kernel.
Since the audit, the project has moved to separate per-process address spaces, with user applications running in Ring 3 and entering the kernel only through the SYSCALL/SYSRET interface; other findings have been addressed incrementally as the affected subsystems were reworked.
Current hardening status
The audit's "exploit mitigations" theme called out four missing defenses by
name: ASLR, stack canaries, PIE, and W^X. All four now exist in the tree, plus
several more the audit did not originally call out (SMEP/SMAP, syscall pointer
validation, TLS certificate verification); none of them is complete. Rather
than duplicate that status narrative in two places on this site, where it has
already gone stale once (an earlier version of this section described the
userland stack-canary entropy as a non-CSPRNG interim source; that was fixed
in #654 and the description here had not caught up), the full
claim-by-claim status with its supporting evidence now lives on one page:
Hardening & Mitigations: every mitigation's status (enforced, partial, or planned), the measurement behind it, and the commands to re-check it yourself against a downloaded image.
Roadmap
Remaining hardening themes tracked from the audit, in priority order. Stack canaries, ASLR, PIE, and W^X have moved from "not started" to "shipped with known gaps" (see above) and are no longer listed here as untouched; everything below has not been re-verified in this pass and its status should not be inferred from the items above:
- DMA-safe buffer management and IOMMU protection for device drivers
- Continued hardening of network input parsing, plus rate limiting for flood resistance
- Heap allocator hardening (metadata separation, poisoning of freed memory)
- Consistent kernel-wide error-code conventions
The full audit log, including per-finding technical detail and remediation tracking, is maintained internally.