CVE-2024-46735

What it actually does

NULL pointer dereference in ublk_ctrl_start_recovery when multiple UBLK_CMD_START_USER_RECOVERY commands race; first clears ubq->ubq_daemon while second dereferences it via ublk_queue_reinit after nr_queues_ready check is absent.

Why it matters to the business

Kernel panic and system crash on hosts using ublk devices, causing unplanned downtime and potential loss of block I/O services; no widespread ransomware association but high operational impact on affected Linux deployments.

How an attack unfolds

Local attacker with access to submit uring commands issues two UBLK_CMD_START_USER_RECOVERY operations in rapid succession; the first nulls the daemon pointer and the second bypasses the missing guard, triggering the dereference during io_uring command handling in the kernel worker.

How to fix it

Upgrade the Linux kernel to commit ca249435893dda766f3845c15ca77ca5672022d8 or later; for any downstream packages such as fbthrift update to 0.31.1-0.20190225164308-c461c1bd1a3e where applicable. Reboot after patching.

How to confirm the fix worked

Verify running kernel contains the fix commit; attempt to reproduce the double recovery command sequence in a test environment and confirm absence of NULL dereference oops; monitor nr_queues_ready checks in ublk_ctrl_start_recovery.

Typical attack path

1. Obtain local access or capability to issue io_uring commands against ublk
2. Submit first UBLK_CMD_START_USER_RECOVERY to clear ubq_daemon
3. Immediately submit second identical command before queue reinit completes
4. Trigger page fault and kernel oops leading to panic

How to detect it

Inspect kernel logs and crash dumps for 'BUG: kernel NULL pointer dereference' with RIP referencing ublk_ctrl_start_recovery.constprop.0; correlate with io_uring worker threads and ublk queue reinit activity; review threat actor reports of Linux kernel resource and write issues for similar patterns.

• ublk_ctrl_start_recovery.constprop.0+0x82/0x180
• BUG: kernel NULL pointer dereference, address: 0000000000000028
• Call Trace containing ublk_ctrl_uring_cmd and io_wq_worker

What your security team should do

• Apply kernel patch immediately on all systems exposing ublk devices
• Prioritize hosts with high ublk usage due to 754 days since publication
• Add monitoring for ublk-related kernel faults in crash dumps
• Review io_uring usage policies to limit untrusted command submission