[PATCH] mm/swap: reject swapon() on filesystem-level encrypted files

[PATCH] mm/swap: reject swapon() on filesystem-level encrypted files

[Eric Biggers]

ext4 and f2fs don't prevent filesystem-level encrypted files from being
set up directly as swap files.  In this case, encryption is bypassed.

No one should be doing this, vs. the methods of encrypted swap that
actually do work (such as swapping to a dm-crypt device, or swapping to
a loopback device on top of a filesystem-level encrypted file).

Nevertheless, to prevent user error, make swapon() explicitly reject
this case.  Document this behavior in fscrypt.rst as well.

Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
 Documentation/filesystems/fscrypt.rst | 4 ++++
 mm/swapfile.c                         | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
index c0dd35f1af12..cba1989777da 100644
--- a/Documentation/filesystems/fscrypt.rst
+++ b/Documentation/filesystems/fscrypt.rst
@@ -1238,6 +1238,10 @@ astute users may notice some differences in behavior:
 
 - DAX (Direct Access) is not supported on encrypted files.
 
+- Encrypted files cannot be used directly as swap files.  To swap to
+  an encrypted file, set up a loopback device on top of it.
+  Alternatively, encrypted swap can use a dm-crypt device instead.
+
 - The maximum length of an encrypted symlink is 2 bytes shorter than
   the maximum length of an unencrypted symlink.  For example, on an
   EXT4 filesystem with a 4K block size, unencrypted symlinks can be up
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 78b49b0658ad..e4991da81b5f 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -3650,6 +3650,10 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
 		error = -EBUSY;
 		goto bad_swap_unlock_inode;
 	}
+	if (IS_ENCRYPTED(inode)) {
+		error = -EINVAL;
+		goto bad_swap_unlock_inode;
+	}
 
 	/*
 	 * The swap subsystem needs a major overhaul to support this.

base-commit: f5098b6bae761e346ebcd9da7f95622c04733cff
-- 
2.55.0

Re: [PATCH] mm/swap: reject swapon() on filesystem-level encrypted files

[Andrew Morton]

On Thu, 30 Jul 2026 11:48:53 -0700 Eric Biggers <ebiggers@kernel.org> wrote:

> ext4 and f2fs don't prevent filesystem-level encrypted files from being
> set up directly as swap files.  In this case, encryption is bypassed.
> 
> No one should be doing this, vs. the methods of encrypted swap that
> actually do work (such as swapping to a dm-crypt device, or swapping to
> a loopback device on top of a filesystem-level encrypted file).
> 
> Nevertheless, to prevent user error, make swapon() explicitly reject
> this case.  Document this behavior in fscrypt.rst as well.
> 
> Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
> Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support")

Ouch.  We are going to break ten year old setups?  I don't think we can
do this!

I think the best we can do is to emit loud warnings which point the
operator to some Documentation/ which tells operator that this
deprecated configuration will be disallowed in, umm, 2029.

> +  Alternatively, encrypted swap can use a dm-crypt device instead.

That's tautological.  s/ intead// ;)

Re: [PATCH] mm/swap: reject swapon() on filesystem-level encrypted files

[Eric Biggers]

On Thu, Jul 30, 2026 at 12:53:27PM -0700, Andrew Morton wrote:
> On Thu, 30 Jul 2026 11:48:53 -0700 Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > ext4 and f2fs don't prevent filesystem-level encrypted files from being
> > set up directly as swap files.  In this case, encryption is bypassed.
> > 
> > No one should be doing this, vs. the methods of encrypted swap that
> > actually do work (such as swapping to a dm-crypt device, or swapping to
> > a loopback device on top of a filesystem-level encrypted file).
> > 
> > Nevertheless, to prevent user error, make swapon() explicitly reject
> > this case.  Document this behavior in fscrypt.rst as well.
> > 
> > Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
> > Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support")
> 
> Ouch.  We are going to break ten year old setups?  I don't think we can
> do this!

That assumes anyone is actually depending on this bug, which they
probably aren't.  Encrypted swap is done in other ways.

> I think the best we can do is to emit loud warnings which point the
> operator to some Documentation/ which tells operator that this
> deprecated configuration will be disallowed in, umm, 2029.

... and if they are, they'll want to fix it right away anyway, not in
2029.

Other fixes to explicitly disallow swapfile activation in various cases
have been merged without a deprecation period, e.g. 36e4d95891ed,
377eeaa8e11f, 51cc3a6620a6, d15cab975459.

I think we should try just doing this instead of dragging it out over
several years.

- Eric

Re: [PATCH] mm/swap: reject swapon() on filesystem-level encrypted files

[Darrick J. Wong]

On Thu, Jul 30, 2026 at 08:30:03PM +0000, Eric Biggers wrote:
> On Thu, Jul 30, 2026 at 12:53:27PM -0700, Andrew Morton wrote:
> > On Thu, 30 Jul 2026 11:48:53 -0700 Eric Biggers <ebiggers@kernel.org> wrote:
> > 
> > > ext4 and f2fs don't prevent filesystem-level encrypted files from being
> > > set up directly as swap files.  In this case, encryption is bypassed.
> > > 
> > > No one should be doing this, vs. the methods of encrypted swap that
> > > actually do work (such as swapping to a dm-crypt device, or swapping to
> > > a loopback device on top of a filesystem-level encrypted file).
> > > 
> > > Nevertheless, to prevent user error, make swapon() explicitly reject
> > > this case.  Document this behavior in fscrypt.rst as well.
> > > 
> > > Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
> > > Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support")
> > 
> > Ouch.  We are going to break ten year old setups?  I don't think we can
> > do this!
> 
> That assumes anyone is actually depending on this bug, which they
> probably aren't.  Encrypted swap is done in other ways.

Hmm.  swapon() seems to read the swapfile header via read_mapping_folio,
which means that fscrypt will read the encrypted block 0, decrypt it,
and hand the mm a valid swapfile header, right?

For blockdev filesystem, the setup_swap_extents code will set up a file
range -> LBA mapping, and the swap code issues bios directly to the
bdev.  Ondisk contents aren't encrypted, and read()ing the swapfile will
produce garbage because we're decrypting something that isn't encrypted.

So I guess the bug here is that the ondisk swapfile contents aren't
encrypted?  Can we fix the swap code to call fscrypt_set_bio_crypt_ctx?

Though, you probably don't want anyone to read the non-header swapfile
contents, so can one create an ephemeral encryption key for the swap
code?  Or do you not want crypto engines in the swap path?

(Apologies for my unfiltered idiot thoughts :P)

--D

> 
> > I think the best we can do is to emit loud warnings which point the
> > operator to some Documentation/ which tells operator that this
> > deprecated configuration will be disallowed in, umm, 2029.
> 
> ... and if they are, they'll want to fix it right away anyway, not in
> 2029.
> 
> Other fixes to explicitly disallow swapfile activation in various cases
> have been merged without a deprecation period, e.g. 36e4d95891ed,
> 377eeaa8e11f, 51cc3a6620a6, d15cab975459.
> 
> I think we should try just doing this instead of dragging it out over
> several years.
> 
> - Eric
> 

Re: [PATCH] mm/swap: reject swapon() on filesystem-level encrypted files

[Eric Biggers]

On Thu, Jul 30, 2026 at 08:49:31PM -0700, Darrick J. Wong wrote:
> On Thu, Jul 30, 2026 at 08:30:03PM +0000, Eric Biggers wrote:
> > On Thu, Jul 30, 2026 at 12:53:27PM -0700, Andrew Morton wrote:
> > > On Thu, 30 Jul 2026 11:48:53 -0700 Eric Biggers <ebiggers@kernel.org> wrote:
> > > 
> > > > ext4 and f2fs don't prevent filesystem-level encrypted files from being
> > > > set up directly as swap files.  In this case, encryption is bypassed.
> > > > 
> > > > No one should be doing this, vs. the methods of encrypted swap that
> > > > actually do work (such as swapping to a dm-crypt device, or swapping to
> > > > a loopback device on top of a filesystem-level encrypted file).
> > > > 
> > > > Nevertheless, to prevent user error, make swapon() explicitly reject
> > > > this case.  Document this behavior in fscrypt.rst as well.
> > > > 
> > > > Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
> > > > Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support")
> > > 
> > > Ouch.  We are going to break ten year old setups?  I don't think we can
> > > do this!
> > 
> > That assumes anyone is actually depending on this bug, which they
> > probably aren't.  Encrypted swap is done in other ways.
> 
> Hmm.  swapon() seems to read the swapfile header via read_mapping_folio,
> which means that fscrypt will read the encrypted block 0, decrypt it,
> and hand the mm a valid swapfile header, right?
> 
> For blockdev filesystem, the setup_swap_extents code will set up a file
> range -> LBA mapping, and the swap code issues bios directly to the
> bdev.  Ondisk contents aren't encrypted, and read()ing the swapfile will
> produce garbage because we're decrypting something that isn't encrypted.
> 
> So I guess the bug here is that the ondisk swapfile contents aren't
> encrypted?  Can we fix the swap code to call fscrypt_set_bio_crypt_ctx?
> 
> Though, you probably don't want anyone to read the non-header swapfile
> contents, so can one create an ephemeral encryption key for the swap
> code?  Or do you not want crypto engines in the swap path?
> 
> (Apologies for my unfiltered idiot thoughts :P)

Well, the direct swapfile implementation bypasses the filesystem after
the header has been read and the on-disk blocks have been queried.  That
seems to be very much what it's designed to do.  It seems out of scope
for it to start trying to implement filesystem features like fscrypt
file contents encryption.  (Note that there's more to it than calling
fscrypt_set_bio_crypt_ctx(), especially in current mainline.)  After
all, we also wouldn't expect it to understand and implement the
compression, checksums, etc. features of various filesystems.

Yes, when people encrypt their swap, they of course use an ephemeral
key.  However, they use either dm-crypt, or a loop device on top of an
fscrypt file.  (Note that if they use zram with a backing file, they
*have* to use a block device anyway.)

Fortunately, I've never heard of someone actually using the direct
swapon() with an fscrypt file, which is what this patch pertains to.
This case was just found by an LLM review.  I don't think we need to add
a new feature here; we should just remove the footgun just in case.

- Eric

Re: [PATCH] mm/swap: reject swapon() on filesystem-level encrypted files

[Baoquan He]

On 07/30/26 at 11:48am, Eric Biggers wrote:
> ext4 and f2fs don't prevent filesystem-level encrypted files from being
> set up directly as swap files.  In this case, encryption is bypassed.
> 
> No one should be doing this, vs. the methods of encrypted swap that
> actually do work (such as swapping to a dm-crypt device, or swapping to
> a loopback device on top of a filesystem-level encrypted file).
> 
> Nevertheless, to prevent user error, make swapon() explicitly reject
> this case.  Document this behavior in fscrypt.rst as well.
> 
> Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
> Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>  Documentation/filesystems/fscrypt.rst | 4 ++++
>  mm/swapfile.c                         | 4 ++++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
> index c0dd35f1af12..cba1989777da 100644
> --- a/Documentation/filesystems/fscrypt.rst
> +++ b/Documentation/filesystems/fscrypt.rst
> @@ -1238,6 +1238,10 @@ astute users may notice some differences in behavior:
>  
>  - DAX (Direct Access) is not supported on encrypted files.
>  
> +- Encrypted files cannot be used directly as swap files.  To swap to
> +  an encrypted file, set up a loopback device on top of it.
> +  Alternatively, encrypted swap can use a dm-crypt device instead.
> +
>  - The maximum length of an encrypted symlink is 2 bytes shorter than
>    the maximum length of an unencrypted symlink.  For example, on an
>    EXT4 filesystem with a 4K block size, unencrypted symlinks can be up
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 78b49b0658ad..e4991da81b5f 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -3650,6 +3650,10 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
>  		error = -EBUSY;
>  		goto bad_swap_unlock_inode;
>  	}
> +	if (IS_ENCRYPTED(inode)) {
> +		error = -EINVAL;
> +		goto bad_swap_unlock_inode;
> +	}

Sounds reasonable to me.

One minor suggestion: it might be helpful to emit a pr_warn_once()
explaining *why* the swapon was rejected and pointing users to the
dm-crypt / loopback alternatives, so the -EINVAL isn't opaque.
Optional though -- the check itself is what matters.

And this patch updates fscrypt.rst. Would it be good to also
update the swapon(8) man page to document the new -EINVAL
condition?

Other than these,

Reviewed-by: Baoquan He <baoquan.he@linux.dev>


>  
>  	/*
>  	 * The swap subsystem needs a major overhaul to support this.
> 
> base-commit: f5098b6bae761e346ebcd9da7f95622c04733cff
> -- 
> 2.55.0
>