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 prote

A deep dive into Linux’s new mseal syscall

submited by

Style Pass

2024-10-25 15:00:02

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.

If you’re like me and followed the spicy discourse surrounding this syscall in the kernel mailing lists, you may have observed that Chrome’s Security team introduced it to support their V8 CFI strategy, initially for Linux-based ChromeOS. After some lengthy deliberation and several rewrites, it finally landed in the kernel, with plans to expand its use case beyond browsers with its integration into glibc, possibly in version 2.41.