Security hole in the Linux kernel
Summary
In January 2004 Paul Starzetz reported a critical hole in the memory management of Linux kernels 2.2, 2.4 and 2.6. An insufficient check in do_mremap() made it possible to create a virtual memory area with a length of zero bytes and thus confuse memory management. Since mremap(2) requires no special privileges, any process could exploit the hole; an unpublished exploit delivered a root shell.
Ideas
- An edge case such as a length of zero bytes threw memory management off track.
- Any unprivileged process could use the system call.
- Starzetz deliberately held back the working exploit.
Insights
- Boundary values such as zero or maximum lengths are the most frequent causes of kernel holes.
- Responsible disclosure gives operators time without concealing the risk.
Facts
- Kernel series 2.2, 2.4 and 2.6 were affected.
- The bug was in the do_mremap() function.
References
Critique
- The report names no fixed kernel versions that administrators could go by.
Recommendations
- Test your own interfaces specifically with boundary values such as zero, negative and maximum.
- Apply kernel updates with high priority on systems with local users.
Links to the original source and the Web Archive open in a new tab.