CVE-2023-53810

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: release crypto keyslot before reporting I/O complete<br /> <br /> Once all I/O using a blk_crypto_key has completed, filesystems can call<br /> blk_crypto_evict_key(). However, the block layer currently doesn&amp;#39;t call<br /> blk_crypto_put_keyslot() until the request is being freed, which happens<br /> after upper layers have been told (via bio_endio()) the I/O has<br /> completed. This causes a race condition where blk_crypto_evict_key()<br /> can see &amp;#39;slot_refs != 0&amp;#39; without there being an actual bug.<br /> <br /> This makes __blk_crypto_evict_key() hit the<br /> &amp;#39;WARN_ON_ONCE(atomic_read(&amp;slot-&gt;slot_refs) != 0)&amp;#39; and return without<br /> doing anything, eventually causing a use-after-free in<br /> blk_crypto_reprogram_all_keys(). (This is a very rare bug and has only<br /> been seen when per-file keys are being used with fscrypt.)<br /> <br /> There are two options to fix this: either release the keyslot before<br /> bio_endio() is called on the request&amp;#39;s last bio, or make<br /> __blk_crypto_evict_key() ignore slot_refs. Let&amp;#39;s go with the first<br /> solution, since it preserves the ability to report bugs (via<br /> WARN_ON_ONCE) where a key is evicted while still in-use.