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 classified as critical. The impacted element is the function blk_crypto_evict_key. Performing a manipulation results in use after free. This vulnerability is reported as CVE-2023-53810. No exploit exists. Upgrading the affected component is recommended.

Detailsinfo

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 classified as critical. This affects the function blk_crypto_evict_key. The manipulation with an unknown input leads to a use after free vulnerability. CWE is classifying the issue as CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

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.

It is possible to read the advisory at git.kernel.org. This vulnerability is uniquely identified as CVE-2023-53810 since 12/09/2025. The exploitability is told to be easy. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 03/29/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 874bdf43b4a7dc5463c31508f62b3e42eb237b08/d206f79d9cd658665b37ce8134c6ec849ac7af0c/7d206ec7a04e8545828191b6ea8b49d3ea61391f/b278570e2c59d538216f8b656e97680188a8fba4/92d5d233b9ff531cf9cc36ab4251779e07adb633/9cd1e566676bbcb8a126acd921e4e194e6339603 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 vulnerability database at CERT Bund (WID-SEC-2025-2765). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• Open Source Linux Kernel
• RESF Rocky Linux

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

Discussion