CVE-2024-50182

What it actually does

memfd_secret() syscall succeeds on arm64 systems where !can_set_direct_map() but set_direct_map_invalid_noflush() is a no-op returning success, so pages remain present in the direct map instead of being removed.

Why it matters to the business

Systems relying on secret memory isolation on certain arm64 configurations may leak sensitive data that should have been protected, raising exposure risk for applications using the feature.

How an attack unfolds

An attacker on an affected arm64 system calls memfd_secret(), receives a valid fd, maps and faults pages, then reads the contents via the direct map since the invalidation step silently did nothing.

How to fix it

Apply the upstream kernel fix that returns -ENOSYS from memfd_secret() when !can_set_direct_map(); on affected arm64 systems enable CONFIG_RODATA_FULL_DEFAULT_ENABLED or upgrade to a kernel containing the check.

How to confirm the fix worked

Confirm can_set_direct_map() returns false on the target configuration, then verify memfd_secret() now returns -ENOSYS; test that pages are no longer reachable via the direct map after the call.

Typical attack path

1. Confirm target runs arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n and related options disabled
2. Invoke memfd_secret() syscall and verify it returns a valid file descriptor
3. mmap the fd and trigger page faults to populate memory
4. Read or dump memory contents through the direct map to access supposed secrets

How to detect it

Review kernel logs for memfd_secret calls returning success on arm64 systems with restricted direct-map support; inspect process memory mappings and direct-map page table entries for unexpected presence of secret pages.

What your security team should do

• Prioritize kernel updates on arm64 systems lacking 4k direct-map granularity
• Audit workloads using memfd_secret() and disable the syscall where the feature cannot be enforced
• Monitor for future kernel releases addressing secretmem on additional arm64 configurations