CVE-2026-63952: memfd: deny writeable mappings when implying SEAL_WRITE
In the Linux kernel, the following vulnerability has been resolved:
memfd: deny writeable mappings when implying SEALWRITE
When SEALEXEC is added, SEALWRITE is implied to make W^X. But the implied seal is set after the check that makes sure the memfd can not have any writable mappings. This means one can use SEALEXEC to apply SEALWRITE while having writeable mappings.
This breaks the contract that SEALWRITE provides and can be used by an attacker to pass a memfd that appears to be write sealed but can still be modified arbitrarily.
Fix this by adding the implied seals before the call for mappingdenywritable() is done.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.94-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.0.12-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.143 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.93 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.35 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.0.12
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs local access and low-privileged access sufficient to create and manipulate a memfd. No user interaction is required.
What condition is required for exploitation?
The attacker must retain writable mappings of a memfd while adding SEAL_EXEC, which implies SEAL_WRITE. The resulting memfd can appear write-sealed while still being arbitrarily modifiable through those mappings.
What security property is affected?
The issue breaks the expected SEAL_WRITE guarantee and the write-xor-execute behavior intended when SEAL_EXEC is applied. A consumer that trusts the memfd's write-sealed state could receive content that can subsequently be changed.
What does the fix change?
The fix applies implied seals, including SEAL_WRITE from SEAL_EXEC, before checking for writable mappings. This prevents adding the implied write seal while writable mappings still exist.