CVE-2023-54088

What it actually does

Race condition in blk-cgroup allows removal of blkg from q->blkg_list without holding queue_lock, leading to list corruption or hard lockups when blkg_destroy_all is invoked from blkg_free_workfn.

Why it matters to the business

Linux systems may experience unexpected kernel crashes or freezes during block device or cgroup operations, causing downtime for storage-dependent workloads and requiring reboots to recover.

How an attack unfolds

An attacker with local access triggers concurrent block cgroup operations that race during blkg removal; the missing lock allows blkg_destroy_all to corrupt internal lists, resulting in system instability or denial of service.

How to fix it

Upgrade the Linux kernel to version 6.1.17 or later, or apply commit b5dae1cd0d8368b4338430ff93403df67f0b8bcc from the stable git repository.

How to confirm the fix worked

Confirm the running kernel version is 6.1.17 or newer; inspect the blk-cgroup.c source for the queue_lock acquisition around blkg q_node removal.

Typical attack path

1. Obtain local unprivileged access on a Linux system
2. Perform concurrent operations involving block devices and cgroups
3. Trigger blkg_free_workfn while blkg_destroy_all runs without queue_lock
4. Cause list corruption or hard lockup leading to kernel panic

How to detect it

Review kernel logs for list corruption warnings, hard lockup messages, or panics originating from blk-cgroup or blkg_destroy_all routines.

What your security team should do

• Prioritize kernel upgrades on all production Linux hosts within the next maintenance window
• Monitor for kernel oops or hard lockup reports in system logs
• Test the updated kernel in staging environments before broad deployment