CVE-2024-36478

What it actually does

Concurrent writes to the 'power' and 'submit_queues' configfs attributes in the null_blk driver allow del_gendisk to race with blk_mq_update_nr_hw_queues, resulting in a null pointer dereference when dev->nullb is cleared while the queue update still executes.

Why it matters to the business

Systems using the null_blk kernel module for block-device emulation can experience kernel panics and immediate reboots when configuration changes occur concurrently, disrupting testing, development, or specialized storage workloads and requiring manual recovery.

How an attack unfolds

An attacker with write access to /sys/kernel/config/nullb/ repeatedly toggles the power attribute while another process rapidly changes submit_queues; the resulting race in nullb_device_power_store versus nullb_device_submit_queues_store triggers the null dereference inside the block layer's debugfs and queue-update paths, causing a kernel panic.

How to fix it

Apply the upstream fix in commit 1d4c8baef435c98e8d5aa7027dc5a9f70834ba16 or later; rebuild and boot the patched kernel. Disable or avoid concurrent configuration of null_blk devices via configfs until the update is installed.

How to confirm the fix worked

Confirm the running kernel contains commit 1d4c8baef435c98e8d5aa7027dc5a9f70834ba16 or equivalent backport; re-execute the published race-condition reproducer and verify absence of the NULL pointer oops in dmesg.

Typical attack path

1. Load null_blk with nr_devices=0 via modprobe
2. Create a nullb device directory under /sys/kernel/config/nullb/
3. Spawn two loops: one repeatedly writing 1/0 to the power attribute and the other writing varying values to submit_queues
4. Trigger the race condition that leads to concurrent del_gendisk and blk_mq_update_nr_hw_queues
5. Cause NULL pointer dereference and kernel panic

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for the signature 'BUG: kernel NULL pointer dereference' followed by the call trace containing nullb_device_submit_queues_store, nullb_update_nr_hw_queues, and blk_mq_update_nr_hw_queues; also look for repeated configfs writes to null_blk power and submit_queues attributes in audit logs or process accounting.

• BUG: kernel NULL pointer dereference, address: 0000000000000148
• nullb_device_submit_queues_store+0x79/0xf0 [null_blk]
• nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
• blk_mq_update_nr_hw_queues+0x4a3/0x720
• simple_recursive_removal+0x12f/0x5c0
• modprobe null_blk nr_devices=0
• /sys/kernel/config/nullb/nullb0/submit_queues
• /sys/kernel/config/nullb/nullb0/power

What your security team should do

• Immediately upgrade any Linux kernel using null_blk to a version containing commit 1d4c8baef435c98e8d5aa7027dc5a9f70834ba16
• Restrict write access to /sys/kernel/config/nullb/ to the minimum required users or disable configfs null_blk exposure on production systems
• Monitor kernel logs for null_blk-related oops messages and schedule emergency reboots if detected
• Add null_blk to the list of modules that trigger mandatory kernel updates during the next maintenance window