]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
fscrypt: use READ_ONCE() to access ->i_crypt_info
authorEric Biggers <ebiggers@google.com>
Thu, 11 Apr 2019 21:32:15 +0000 (14:32 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 31 May 2019 13:43:32 +0000 (06:43 -0700)
commit8bcc53fb09779ea011623e7766f56e2ea24bdcf0
treea7a3959090210f78b52ec6c3bbd7c11eb4d577ad
parentd66a2891b79962cfa742967844da7fc5d9bdab87
fscrypt: use READ_ONCE() to access ->i_crypt_info

[ Upstream commit e37a784d8b6a1e726de5ddc7b4809c086a08db09 ]

->i_crypt_info starts out NULL and may later be locklessly set to a
non-NULL value by the cmpxchg() in fscrypt_get_encryption_info().

But ->i_crypt_info is used directly, which technically is incorrect.
It's a data race, and it doesn't include the data dependency barrier
needed to safely dereference the pointer on at least one architecture.

Fix this by using READ_ONCE() instead.  Note: we don't need to use
smp_load_acquire(), since dereferencing the pointer only requires a data
dependency barrier, which is already included in READ_ONCE().  We also
don't need READ_ONCE() in places where ->i_crypt_info is unconditionally
dereferenced, since it must have already been checked.

Also downgrade the cmpxchg() to cmpxchg_release(), since RELEASE
semantics are sufficient on the write side.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fs/crypto/crypto.c
fs/crypto/fname.c
fs/crypto/keyinfo.c
fs/crypto/policy.c
include/linux/fscrypt.h