• Eric Biggers's avatar
    fscrypt: lock mutex before checking for bounce page pool · a0b3bc85
    Eric Biggers authored
    fscrypt_initialize(), which allocates the global bounce page pool when
    an encrypted file is first accessed, uses "double-checked locking" to
    try to avoid locking fscrypt_init_mutex.  However, it doesn't use any
    memory barriers, so it's theoretically possible for a thread to observe
    a bounce page pool which has not been fully initialized.  This is a
    classic bug with "double-checked locking".
    
    While "only a theoretical issue" in the latest kernel, in pre-4.8
    kernels the pointer that was checked was not even the last to be
    initialized, so it was easily possible for a crash (NULL pointer
    dereference) to happen.  This was changed only incidentally by the large
    refactor to use fs/crypto/.
    
    Solve both problems in a trivial way that can easily be backported: just
    always take the mutex.  It's theoretically less efficient, but it
    shouldn't be noticeable in practice as the mutex is only acquired very
    briefly once per encrypted file.
    
    Later I'd like to make this use a helper macro like DO_ONCE().  However,
    DO_ONCE() runs in atomic context, so we'd need to add a new macro that
    allows blocking.
    
    Cc: stable@vger.kernel.org # v4.1+
    Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
    Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    a0b3bc85
crypto.c 13.6 KB