[PATCH 0/3] Fix crash with fscrypt + Landlock

[PATCH 0/3] Fix crash with fscrypt + Landlock

[Eric Biggers]

This series fixes a bug, found by syzbot, where when a filesystem was
being unmounted, the fscrypt keyring was destroyed before inodes have
been released by the Landlock LSM.

Eric Biggers (3):
  fscrypt: destroy keyring after security_sb_delete()
  fscrypt: improve fscrypt_destroy_keyring() documentation
  fscrypt: check for NULL keyring in fscrypt_put_master_key_activeref()

 fs/crypto/keyring.c | 23 +++++++++++++----------
 fs/super.c          | 15 ++++++++++++---
 2 files changed, 25 insertions(+), 13 deletions(-)


base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
-- 
2.39.2

[PATCH 1/3] fscrypt: destroy keyring after security_sb_delete()

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

fscrypt_destroy_keyring() must be called after all potentially-encrypted
inodes were evicted; otherwise it cannot safely destroy the keyring.
Since inodes that are in-use by the Landlock LSM don't get evicted until
security_sb_delete(), this means that fscrypt_destroy_keyring() must be
called *after* security_sb_delete().

This fixes a WARN_ON followed by a NULL dereference, only possible if
Landlock was being used on encrypted files.

Fixes: d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key")
Cc: stable@vger.kernel.org
Reported-by: syzbot+93e495f6a4f748827c88@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/00000000000044651705f6ca1e30@google.com
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 fs/super.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/fs/super.c b/fs/super.c
index 84332d5cb817a..04bc62ab7dfea 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -475,13 +475,22 @@ void generic_shutdown_super(struct super_block *sb)
 
 		cgroup_writeback_umount();
 
-		/* evict all inodes with zero refcount */
+		/* Evict all inodes with zero refcount. */
 		evict_inodes(sb);
-		/* only nonzero refcount inodes can have marks */
+
+		/*
+		 * Clean up and evict any inodes that still have references due
+		 * to fsnotify or the security policy.
+		 */
 		fsnotify_sb_delete(sb);
-		fscrypt_destroy_keyring(sb);
 		security_sb_delete(sb);
 
+		/*
+		 * Now that all potentially-encrypted inodes have been evicted,
+		 * the fscrypt keyring can be destroyed.
+		 */
+		fscrypt_destroy_keyring(sb);
+
 		if (sb->s_dio_done_wq) {
 			destroy_workqueue(sb->s_dio_done_wq);
 			sb->s_dio_done_wq = NULL;
-- 
2.39.2

Re: [PATCH 1/3] fscrypt: destroy keyring after security_sb_delete()

[Christian Brauner]

On Mon, Mar 13, 2023 at 03:12:29PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> fscrypt_destroy_keyring() must be called after all potentially-encrypted
> inodes were evicted; otherwise it cannot safely destroy the keyring.
> Since inodes that are in-use by the Landlock LSM don't get evicted until
> security_sb_delete(), this means that fscrypt_destroy_keyring() must be
> called *after* security_sb_delete().
> 
> This fixes a WARN_ON followed by a NULL dereference, only possible if
> Landlock was being used on encrypted files.
> 
> Fixes: d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key")
> Cc: stable@vger.kernel.org
> Reported-by: syzbot+93e495f6a4f748827c88@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/r/00000000000044651705f6ca1e30@google.com
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---

Looks good,
Reviewed-by: Christian Brauner <brauner@kernel.org>

[PATCH 2/3] fscrypt: improve fscrypt_destroy_keyring() documentation

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Document that it must be called after all potentially-encrypted inodes
have been evicted.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 fs/crypto/keyring.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index 78086f8dbda52..bb15709ac9a40 100644
--- a/fs/crypto/keyring.c
+++ b/fs/crypto/keyring.c
@@ -207,10 +207,11 @@ static int allocate_filesystem_keyring(struct super_block *sb)
  * Release all encryption keys that have been added to the filesystem, along
  * with the keyring that contains them.
  *
- * This is called at unmount time.  The filesystem's underlying block device(s)
- * are still available at this time; this is important because after user file
- * accesses have been allowed, this function may need to evict keys from the
- * keyslots of an inline crypto engine, which requires the block device(s).
+ * This is called at unmount time, after all potentially-encrypted inodes have
+ * been evicted.  The filesystem's underlying block device(s) are still
+ * available at this time; this is important because after user file accesses
+ * have been allowed, this function may need to evict keys from the keyslots of
+ * an inline crypto engine, which requires the block device(s).
  */
 void fscrypt_destroy_keyring(struct super_block *sb)
 {
@@ -227,12 +228,12 @@ void fscrypt_destroy_keyring(struct super_block *sb)
 
 		hlist_for_each_entry_safe(mk, tmp, bucket, mk_node) {
 			/*
-			 * Since all inodes were already evicted, every key
-			 * remaining in the keyring should have an empty inode
-			 * list, and should only still be in the keyring due to
-			 * the single active ref associated with ->mk_secret.
-			 * There should be no structural refs beyond the one
-			 * associated with the active ref.
+			 * Since all potentially-encrypted inodes were already
+			 * evicted, every key remaining in the keyring should
+			 * have an empty inode list, and should only still be in
+			 * the keyring due to the single active ref associated
+			 * with ->mk_secret.  There should be no structural refs
+			 * beyond the one associated with the active ref.
 			 */
 			WARN_ON(refcount_read(&mk->mk_active_refs) != 1);
 			WARN_ON(refcount_read(&mk->mk_struct_refs) != 1);
-- 
2.39.2

[PATCH 3/3] fscrypt: check for NULL keyring in fscrypt_put_master_key_activeref()

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

It is a bug for fscrypt_put_master_key_activeref() to see a NULL
keyring.  But it used to be possible due to the bug, now fixed, where
fscrypt_destroy_keyring() was called before security_sb_delete().  To be
consistent with how fscrypt_destroy_keyring() uses WARN_ON for the same
issue, WARN and leak the fscrypt_master_key if the keyring is NULL
instead of dereferencing the NULL pointer.

This is a robustness improvement, not a fix.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 fs/crypto/keyring.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index bb15709ac9a40..13d336a6cc5da 100644
--- a/fs/crypto/keyring.c
+++ b/fs/crypto/keyring.c
@@ -92,6 +92,8 @@ void fscrypt_put_master_key_activeref(struct super_block *sb,
 	 * destroying any subkeys embedded in it.
 	 */
 
+	if (WARN_ON(!sb->s_master_keys))
+		return;
 	spin_lock(&sb->s_master_keys->lock);
 	hlist_del_rcu(&mk->mk_node);
 	spin_unlock(&sb->s_master_keys->lock);
-- 
2.39.2