CVE-2023-53810: blk-mq: release crypto keyslot before reporting I/O complete

CVE-2023-53810: blk-mq: release crypto keyslot before reporting I/O complete

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

blk-mq: release crypto keyslot before reporting I/O complete

Once all I/O using a blk_crypto_key has completed, filesystems can call
blk_crypto_evict_key().  However, the block layer currently doesn't call
blk_crypto_put_keyslot() until the request is being freed, which happens
after upper layers have been told (via bio_endio()) the I/O has
completed.  This causes a race condition where blk_crypto_evict_key()
can see 'slot_refs != 0' without there being an actual bug.

This makes __blk_crypto_evict_key() hit the
'WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)' and return without
doing anything, eventually causing a use-after-free in
blk_crypto_reprogram_all_keys().  (This is a very rare bug and has only
been seen when per-file keys are being used with fscrypt.)

There are two options to fix this: either release the keyslot before
bio_endio() is called on the request's last bio, or make
__blk_crypto_evict_key() ignore slot_refs.  Let's go with the first
solution, since it preserves the ability to report bugs (via
WARN_ON_ONCE) where a key is evicted while still in-use.

The Linux kernel CVE team has assigned CVE-2023-53810 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.8 with commit a892c8d52c02284076fbbacae6692aa5c5807d11 and fixed in 5.10.180 with commit 874bdf43b4a7dc5463c31508f62b3e42eb237b08
	Issue introduced in 5.8 with commit a892c8d52c02284076fbbacae6692aa5c5807d11 and fixed in 5.15.111 with commit d206f79d9cd658665b37ce8134c6ec849ac7af0c
	Issue introduced in 5.8 with commit a892c8d52c02284076fbbacae6692aa5c5807d11 and fixed in 6.1.28 with commit 7d206ec7a04e8545828191b6ea8b49d3ea61391f
	Issue introduced in 5.8 with commit a892c8d52c02284076fbbacae6692aa5c5807d11 and fixed in 6.2.15 with commit b278570e2c59d538216f8b656e97680188a8fba4
	Issue introduced in 5.8 with commit a892c8d52c02284076fbbacae6692aa5c5807d11 and fixed in 6.3.2 with commit 92d5d233b9ff531cf9cc36ab4251779e07adb633
	Issue introduced in 5.8 with commit a892c8d52c02284076fbbacae6692aa5c5807d11 and fixed in 6.4 with commit 9cd1e566676bbcb8a126acd921e4e194e6339603

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-53810
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	block/blk-crypto-internal.h
	block/blk-crypto.c
	block/blk-merge.c
	block/blk-mq.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/874bdf43b4a7dc5463c31508f62b3e42eb237b08
	https://git.kernel.org/stable/c/d206f79d9cd658665b37ce8134c6ec849ac7af0c
	https://git.kernel.org/stable/c/7d206ec7a04e8545828191b6ea8b49d3ea61391f
	https://git.kernel.org/stable/c/b278570e2c59d538216f8b656e97680188a8fba4
	https://git.kernel.org/stable/c/92d5d233b9ff531cf9cc36ab4251779e07adb633
	https://git.kernel.org/stable/c/9cd1e566676bbcb8a126acd921e4e194e6339603