CVE-2018-1000200

What it actually does

Null pointer dereference in exit_mmap() during OOM kill of processes with mlocked VMAs, triggered when the VM_LOCKED bit is cleared before munlock_vma_pages_all() allowing concurrent unmap_page_range() from the OOM reaper.

Why it matters to the business

Unexpected termination of large memory-locked processes under memory pressure can disrupt critical workloads, reduce system availability, and require manual intervention or restarts on affected Linux systems.

How an attack unfolds

An attacker with local access creates processes that mlock substantial memory regions, then induces memory pressure to invoke the OOM killer; the resulting race between exit_mmap() and the OOM reaper dereferences a null pointer and may crash or destabilize the system.

How to fix it

Upgrade the Linux kernel to a version containing commit 27ae357fa82be5ab73b2ef8d39dcb8ca2563483a or later; rebuild and reboot with the patched kernel; where immediate patching is impossible, limit mlock usage and monitor memory pressure.

How to confirm the fix worked

Verify the running kernel Git commit or version string contains 27ae357fa82be5ab73b2ef8d39dcb8ca2563483a; attempt to reproduce the original OOM + mlock scenario in a test environment and confirm absence of the null dereference.

Typical attack path

1. Obtain local code execution on a vulnerable Linux kernel (4.14-4.16).
2. Allocate and mlock large virtual memory regions in one or more processes.
3. Trigger system-wide memory exhaustion to activate the OOM killer.
4. Observe the kernel null dereference during concurrent exit_mmap() and unmap_page_range().

How to detect it

Inspect kernel logs (dmesg, /var/log/kern.log, journalctl) for OOM killer entries followed by null pointer dereference or exit_mmap/munlock_vma_pages_all stack traces; correlate with processes that were using mlock at the time of the OOM event.

• exit_mmap
• munlock_vma_pages_all
• VM_LOCKED bit cleared before munlock
• oom_reaper unmap_page_range concurrent with exit

What your security team should do

• Prioritize kernel upgrade on all systems running versions 4.14 through 4.16 that use mlock.
• Implement memory limits and monitoring to reduce OOM occurrences.
• Review and reduce unnecessary mlock calls in applications.
• Add kernel version checks to vulnerability scanning pipelines.