summaryrefslogtreecommitdiff
path: root/fs/crypto/keyring.c
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2023-03-14 01:12:31 +0300
committerEric Biggers <ebiggers@google.com>2023-03-19 07:08:03 +0300
commit4bcf6f827a79c59806c695dc280e763c5b6a6813 (patch)
tree5bb1c9c42c6028396fac9e88ac5a4f27470f3f84 /fs/crypto/keyring.c
parent43e5f1d5921128373743585e3275ed9044ef8b8f (diff)
downloadlinux-4bcf6f827a79c59806c695dc280e763c5b6a6813.tar.xz
fscrypt: check for NULL keyring in fscrypt_put_master_key_activeref()
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. Link: https://lore.kernel.org/r/20230313221231.272498-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
Diffstat (limited to 'fs/crypto/keyring.c')
-rw-r--r--fs/crypto/keyring.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index bb15709ac9a4..13d336a6cc5d 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);