CVE-2023-54209

What it actually does

A corner-case path allows blktrace debugfs entries to remain allocated after the associated disk is released, causing a memory leak of kernel debugfs structures.

Why it matters to the business

Repeated triggering on systems that open and close disks after del_gendisk can slowly exhaust kernel memory, leading to degraded performance or eventual denial of service on long-running servers.

How an attack unfolds

An attacker with local access opens a block device before del_gendisk, enables blktrace via ioctl, closes the device without disabling tracing, and repeats the sequence to accumulate leaked debugfs entries.

How to fix it

Update the Linux kernel to a version containing commit aa07e56c6a9c7558165690d14eed4fe8babf34fb or apply the equivalent stable backport that moves blk_trace_shutdown into disk_release().

How to confirm the fix worked

Confirm the running kernel contains commit aa07e56c6a9c7558165690d14eed4fe8babf34fb, then verify no debugfs blktrace directories remain after a disk is unregistered while tracing was previously enabled via ioctl.

Typical attack path

1. Obtain local unprivileged access to a system running an affected kernel
2. Open a block device that will later be unregistered
3. Issue ioctl to enable blktrace after del_gendisk has occurred
4. Close the device without shutting down blktrace
5. Repeat to accumulate leaked debugfs entries

How to detect it

Review kernel logs for repeated blk_trace or debugfs allocation warnings, inspect /sys/kernel/debug/block for orphaned trace directories after device removal, and correlate with processes that performed BLKTRACESETUP ioctls without corresponding shutdowns.

What your security team should do

• Prioritize kernel updates on all systems that expose block devices to untrusted local users
• Monitor EPSS and exploit maturity; current values indicate low immediate risk but patch during normal maintenance windows
• Audit custom kernels or downstream distributions for the missing disk_release shutdown call