CVE-2023-54227

What it actually does

The vulnerability causes a memory leak of block request tags in the blk-mq subsystem when nr_hw_queues is reduced, as newly allocated tags for the smaller queue count are freed on device removal but the excess previously allocated tags are not.

Why it matters to the business

Linux systems using block devices with dynamic queue adjustments may experience gradual kernel memory exhaustion, leading to performance degradation, instability, or crashes in storage-heavy workloads over time.

How an attack unfolds

An attacker with local privileges mounts configfs, loads the null_blk module configured for multiple submit queues, creates and powers on a nullb device to allocate excess tags, reduces the submit_queues value, and removes the device, leaving the excess tags allocated and unfreed.

How to fix it

Update the Linux kernel to include commit c0ef7493e68b8896806a2f598fcffbaa97333405 which ensures tags are freed when shrinking nr_hw_queues.

How to confirm the fix worked

Confirm the fix commit is present in the kernel source tree or reproduce the queue shrink sequence while monitoring tag allocations to verify no leaks occur on device removal.

Typical attack path

1. Mount configfs at /mnt
2. Load null_blk module with nr_devices=0 and submit_queues=8
3. Create nullb0 device directory under configfs
4. Power on the device to allocate 9 tags (8 submit + 1 poll)
5. Reduce submit_queues to 4, resulting in only 5 tags needed
6. Remove the device directory, freeing only the 5 current tags and leaking the other 4

How to detect it

Review kernel logs and memory accounting for blk-mq tag allocations that persist after device removal or queue count reductions; use slabinfo or kmemleak to identify unreleased request_queue or tag structures.

What your security team should do

• Apply the kernel fix containing commit c0ef7493e68b8896806a2f598fcffbaa97333405 to all affected systems
• Prioritize updates for storage servers and virtualized environments using blk-mq devices
• Monitor kernel memory usage and block layer statistics for signs of unexpected tag allocation growth