In the Linux kernel, the following vulnerability has been resolved:
block: fix blktrace debugfs entries leakage
Commit 99d055b4fd4b ("block: remove per-disk debugfs files in
blk_unregister_queue") moves blk_trace_shutdown() from
blk_release_queue() to blk_unregister_queue(), this is safe if blktrace
is created through sysfs, however, there is a regression in corner
case.
blktrace can still be enabled after del_gendisk() through ioctl if
the disk is opened before del_gendisk(), and if blktrace is not shutdown
through ioctl before closing the disk, debugfs entries will be leaked.
Fix this problem by shutdown blktrace in disk_release(), this is safe
because blk_trace_remove() is reentrant.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can leave blktrace debugfs entries behind after a specific disk removal and tracing sequence. The source describes a resource cleanup regression, not data theft or code execution. Severity is not scored, and active exploitation is not reported in the provided sources.
Executive priority
Treat as a routine kernel maintenance item unless affected systems rely heavily on blktrace or dynamic block device operations. No active exploitation or severity score is provided, so prioritize through normal patch cycles while confirming vendor impact.
Technical view
A regression from commit 99d055b4fd4b moved blk_trace_shutdown() to blk_unregister_queue(). In a corner case, blktrace can be enabled through ioctl after del_gendisk() if the disk was already open, then debugfs entries leak if tracing is not shut down before close. The fix shuts down blktrace in disk_release().
Likely exposure
Exposure appears limited to Linux kernels containing the listed affected versions or regression commit, with block devices where blktrace is used through ioctl during disk teardown. The sources do not identify affected distributions or privilege requirements.
Exploitation context
CISA KEV status is false in the bundle. The provided sources do not claim active exploitation, public exploit availability, or weaponized use. The described condition requires a specific blktrace and disk lifecycle corner case.
Researcher notes
The core issue is cleanup ordering and reentrancy around blk_trace_remove(). Evidence is limited to the CVE text and stable kernel commits. The bundle lists affected Linux versions 5.19, 6.1.39, 6.3.13, 6.4.4, and 6.5, but distribution mapping is absent.
Mitigation direction
Patch to a Linux kernel release containing the referenced stable fixes.
Check Linux distribution advisories for packaged fixed kernel versions.
Inventory systems running the listed affected Linux kernel versions.
If patching is delayed, note that no source-provided workaround is named.
Validation and detection
Confirm kernel version and vendor backport status on Linux hosts.
Check whether the installed kernel includes the referenced stable commits.
Review whether blktrace/debugfs are used on systems with removable or dynamic disks.
Validate after patching that vendor kernel packages are installed and running.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-54209 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Dec 30, 2025, 12:11 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.