If you love exploit mitigations, you may have heard of a new system call named mseal landing into the Linux kernel’s 6.10 release, providing a protection called “memory sealing.” Beyond notes from the authors, very little information about this mitigation exists. In this blog post, we’ll explain what this syscall is, including how it’s different from prior memory protection schemes and how it works in the kernel to protect virtual memory. We’ll also describe the particular exploit scenarios that mseal helps stop in Linux userspace, such as stopping malicious permissions tampering and preventing memory unmapping attacks.
Memory sealing allows developers to make memory regions immutable from illicit modifications during program runtime. When a virtual memory address (VMA) range is sealed, an attacker with a code execution primitive cannot perform subsequent virtual memory operations to change the VMA’s permissions or modify how it is laid out for their benefit.
...
mseal digresses from prior memory protection schemes on Linux because it is a syscall tailored specifically for exploit mitigation against remote attackers seeking code execution rather than potentially local ones looking to exfiltrate sensitive secrets in-memory.
...
From the disallowed operations, we can discern two particular exploit scenarios that memory sealing will prevent:
- Tampering with a VMA’s permissions. Notably, not allowing executable permissions to be set can stop the revival of shellcode-based attacks.
- “Hole-punching” through arbitrary unmapping/remapping of a memory region, mitigating data-only exploits that take advantage of refilling memory regions with attacker-controlled data.
...
There are likely many other use cases and scenarios that we didn’t cover. After all, mseal is the newest kid on the block in the Linux kernel! As the glibc integration completes and matures, we expect to see improved iterations for the syscall to meet particular demands, including fleshing out the ultimate use of the flags parameter.