Linux Kernel up to 6.3.1 blk_crypto_evict_key use after free

Summaryinfo

A vulnerability was found in Linux Kernel up to 5.10.179/5.15.110/6.1.27/6.2.14/6.3.1. It has been rated as critical. This issue affects the function blk_crypto_evict_key. The manipulation leads to use after free. This vulnerability is traded as CVE-2023-53536. There is no exploit available. Upgrading the affected component is advised.

Detailsinfo

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 5.10.179/5.15.110/6.1.27/6.2.14/6.3.1. This issue affects the function blk_crypto_evict_key. The manipulation with an unknown input leads to a use after free vulnerability. Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

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.

The advisory is shared at git.kernel.org. The identification of this vulnerability is CVE-2023-53536 since 10/04/2025. The exploitation is known to be easy. Technical details are known, but no exploit is available. The price for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 03/01/2026).

Upgrading to version 5.10.180, 5.15.111, 6.1.28, 6.2.15 or 6.3.2 eliminates this vulnerability. Applying the patch 701a8220762ff90615dc91d3543f789391b63298/5bb4005fb667c6e2188fa87950f8d5faf2994410/64ef787bb1588475163069c2e62fdd8f6c27b1f6/809a5be62e92a444a3c3d7b9f438019d0b322f55/5c62852942667c613de0458fc797c5b8c36112b5/5c7cb94452901a93e90c2230632e2c12a681bc92 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at EUVD (EUVD-2023-60072) and CERT Bund (WID-SEC-2025-2194). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Google Container-Optimized OS
• Debian Linux
• Google Cloud Platform
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• Open Source Linux Kernel
• RESF Rocky Linux
• NetApp ActiveIQ Unified Manager
• IBM QRadar SIEM
• Dell NetWorker

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.10.179
• 5.15.110
• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.1.18
• 6.1.19
• 6.1.20
• 6.1.21
• 6.1.22
• 6.1.23
• 6.1.24
• 6.1.25
• 6.1.26
• 6.1.27
• 6.2.0
• 6.2.1
• 6.2.2
• 6.2.3
• 6.2.4
• 6.2.5
• 6.2.6
• 6.2.7
• 6.2.8
• 6.2.9
• 6.2.10
• 6.2.11
• 6.2.12
• 6.2.13
• 6.2.14
• 6.3.0
• 6.3.1

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion