CVE-2023-54209

A debugfs entry leak in the Linux kernel's blktrace subsystem arises from a change in commit 99d055b4fd4b, which moved blk_trace_shutdown() from blk_release_queue() to blk_unregister_queue(). While this is safe for sysfs-based blktrace setup, it introduces a regression: after a disk is removed via del_gendisk(), blktrace can still be enabled through an ioctl if the disk was opened before removal. If the user does not subsequently disable blktrace via ioctl before closing the disk, the associated debugfs entries are never freed, causing a resource leak [1].

The vulnerability requires local access to the system and the ability to issue ioctl commands on a block device. Specifically, an attacker must have the privileges needed to enable blktrace (typically CAP_SYS_ADMIN) and must be able to open the disk before it is removed. The attack surface is limited to systems where users can trigger disk removal while retaining an open file descriptor on the device.

The primary impact is the exhaustion of debugfs entries, which could lead to denial-of-service conditions by consuming kernel memory or preventing further debugfs allocations. No code execution or privilege escalation is implied by the description.

The fix, introduced in commit [1], addresses the leak by calling blk_trace_shutdown() in disk_release(), ensuring that any remaining blktrace state is cleaned up when the disk's last reference is dropped. The function blk_trace_remove() is reentrant, making this safe. Users should apply the latest stable kernel updates to mitigate the issue.