CVE-2023-53531

What it actually does

Race condition between null_poll() and null_timeout_rq() in the null_blk driver allows a NULL pointer dereference during blk_mq timeout handling when poll requests expire under io_uring load.

Why it matters to the business

Kernel panic and system crash on hosts exposing the null block device during I/O benchmarks or testing workloads, leading to unplanned downtime in development or CI environments.

How an attack unfolds

An attacker with local access triggers concurrent poll and timeout paths on /dev/nullb0 via io_uring, causing list_del operations on an already-processed request and subsequent NULL dereference in the timeout workqueue.

How to fix it

Upgrade to a fixed kernel version: Debian 11 uses 5.10.70-1 or later; Debian 12/13/14 use 5.14.9-1 or later; mainline applies commit a0b4a0666beacfe8add9c71d8922475541dbae73. Reboot after update.

How to confirm the fix worked

Verify running kernel version against fixed releases, confirm the patch is present by checking for MQ_RQ_COMPLETE state setting under poll_lock, and test io_uring poll timeout scenarios on nullb0 without oops.

Typical attack path

1. Create and configure null_blk device with poll support
2. Issue io_uring poll requests that will time out
3. Force timeout processing via blk_mq_timeout_work while poll list is being spliced
4. Trigger the unprotected list_del_init on a completed request
5. Cause kernel NULL pointer dereference and panic

How to detect it

Search kernel logs for BUG: kernel NULL pointer dereference combined with null_timeout_rq in the stack trace and workqueue kblockd; examine io_uring activity preceding the crash.

What your security team should do

• Apply the listed kernel updates immediately on all systems exposing null_blk
• Restrict local access to null block devices in production and test environments
• Monitor for kernel oops involving null_timeout_rq and blk_mq_timeout_work
• Review any custom null_blk usage in CI pipelines for exposure