CVE-2016-6224

What it actually does

ecryptfs-setup-swap fails to block activation of unencrypted swap partitions during boot on GPT-formatted NVMe or MMC devices, leaving swap space readable by local processes.

Why it matters to the business

Sensitive data written to swap can be recovered by any local user, increasing risk of credential or data exposure on systems that rely on eCryptfs for encryption.

How an attack unfolds

A local attacker boots or restarts a system using GPT partitioning on an NVMe or MMC drive; the incomplete ecryptfs-setup-swap logic allows the unencrypted swap partition to activate, after which the attacker reads residual plaintext data from the swap device.

How to fix it

Upgrade ecryptfs-utils to a version that fully handles GPT on NVMe/MMC devices, or manually ensure swap is encrypted before enabling it on affected hardware; verify the fix for CVE-2015-8946 is complete.

How to confirm the fix worked

After applying updates, boot on GPT NVMe/MMC hardware and confirm that swap is listed as encrypted by ecryptfs or that the partition is not activated unencrypted; inspect boot logs for ecryptfs-setup-swap output.

Typical attack path

1. Identify or configure a GPT-partitioned NVMe or MMC drive
2. Trigger system boot or reboot so ecryptfs-setup-swap runs
3. Confirm unencrypted swap activation via device mapper or /proc/swaps
4. Read or dump swap contents to recover sensitive information

How to detect it

Examine boot logs for ecryptfs-setup-swap messages indicating swap activation on NVMe/MMC devices; inspect /etc/fstab and /proc/swaps for unencrypted swap entries; search command history or cron jobs for manual swap setup after boot.

What your security team should do

• Prioritize patching ecryptfs-utils on all Ubuntu and derivative systems using NVMe or MMC storage
• Audit boot configurations to ensure swap encryption is enforced regardless of partition table type
• Review systems for any historical unencrypted swap usage and rotate affected credentials