DEBIAN-CVE-2023-53810
- Source
- https://security-tracker.debian.org/tracker/CVE-2023-53810
- Import Source
- https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2023-53810.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/DEBIAN-CVE-2023-53810
- Upstream
- Published
- 2025-12-09T01:16:53.073Z
- Modified
- 2025-12-10T10:17:48.442028Z
- Summary
- [none]
- Details
-
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 blkcryptokey has completed, filesystems can call blkcryptoevictkey(). However, the block layer currently doesn't call blkcryptoputkeyslot() until the request is being freed, which happens after upper layers have been told (via bioendio()) the I/O has completed. This causes a race condition where blkcryptoevictkey() can see 'slotrefs != 0' without there being an actual bug. This makes _blkcryptoevictkey() hit the 'WARNONONCE(atomicread(&slot->slotrefs) != 0)' and return without doing anything, eventually causing a use-after-free in blkcryptoreprogramallkeys(). (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 bioendio() is called on the request's last bio, or make _blkcryptoevictkey() ignore slotrefs. Let's go with the first solution, since it preserves the ability to report bugs (via WARNON_ONCE) where a key is evicted while still in-use.
- References
Affected packages
Debian:11 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Affected ranges
- Type
- ECOSYSTEM
- Events
-
Introduced0Unknown introduced version / All previous versions are affectedFixed5.10.191-1
Affected versions
5.*
Debian:12 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Debian:13 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Debian:14 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source