Bug 2401532 (CVE-2023-53536)

Summary:	CVE-2023-53536 kernel: blk-crypto: make blk_crypto_evict_key() more robust
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	Keywords:	Security
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A use-after-free vulnerability was found in the Linux kernel block layer crypto key management. When blk_crypto_evict_key() fails due to a key still being in-use or keyslot eviction failure during inode eviction, the function returns an error but leaves the key linked in keyslot management structures, causing the caller to free the blk_crypto_key structure regardless of the error, which results in a use-after-free when other code later accesses the freed key and can lead to memory corruption and denial of service.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2025-10-04 16:05:56 UTC

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

blk-crypto: make blk_crypto_evict_key() more robust

If blk_crypto_evict_key() sees that the key is still in-use (due to a
bug) or that ->keyslot_evict failed, it currently just returns while
leaving the key linked into the keyslot management structures.

However, blk_crypto_evict_key() is only called in contexts such as inode
eviction where failure is not an option.  So actually the caller
proceeds with freeing the blk_crypto_key regardless of the return value
of blk_crypto_evict_key().

These two assumptions don't match, and the result is that there can be a
use-after-free in blk_crypto_reprogram_all_keys() after one of these
errors occurs.  (Note, these errors *shouldn't* happen; we're just
talking about what happens if they do anyway.)

Fix this by making blk_crypto_evict_key() unlink the key from the
keyslot management structures even on failure.

Also improve some comments.

Comment 1 Alexander B 2025-10-06 13:28:11 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2025100442-CVE-2023-53536-0e4f@gregkh/T