CVE-2024-50081 - Fixed Linux Kernel Oops via Uninitialized blk-mq tag_set – Details, Code, and Exploit Explained

---

Summary

A recently patched Linux kernel vulnerability, CVE-2024-50081, affected the block multiqueue subsystem (blk-mq). A failure to initialize the tag_set before the hardware context (hctx) could lead to a kernel oops, potentially resulting in a denial of service (DoS). Here’s an exclusive, clear breakdown of the bug, a simple walk-through exploit scenario, patch details, and references.

What’s the Problem?

Code within the Linux kernel's block I/O layer (blk-mq) manages high-performance access to block devices (like SSDs) using job “tags” and hardware queue contexts.

In the faulty versions, if block I/O subsystems began handling CPU hotplug events too early (before the queue’s tag_set pointer got properly set up), then any code referencing it would read a NULL—and that’s a quick way to crash the kernel (a kernel “oops”).

Vulnerable Code Location

- Subsystem: block/blk-mq.c

2. At the same time, CPU hotplug handlers are enabled

3. But, the queue’s tag_set is not yet set up, so a NULL pointer access happens if the hotplug handler runs in that window

This is a classic case of order-of-initialization error.

How Could It Be Exploited?

A local user with the ability to trigger CPU hotplug events (like plugging or unplugging CPU cores, which is doable on many hypervisor VMs and physical servers), or even manipulating block devices (sometimes unprivileged in certain sandboxed setups), could provoke a kernel oops:

The kernel is running with the buggy code (before the fix).

2. A new block device is added, or the system reconfigures queues for a device (ex: after adding/removing CPUs).

Code Snippet: Vulnerable Path (Before the Patch)

// In block/blk-mq.c, simplied
void blk_mq_init_hctx(struct request_queue *q, ...) {
    // [snip]
    cpuhp_state_add_installed(..., hctx_cpuhp_handler); // handler might deref tag_set
    q->tag_set = tag_set;   // tag_set assigned too late!
}

Crashing Stack (Example)

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
...
blk_mq_hctx_has_cpu()
blk_mq_update_queue_map()
blk_mq_cpu_online()

The Fix: Correct Initialization Order

The fix is about initializing the tag_set before enabling any handler that might read it.

Patch Diff

// Patched blk-mq.c pseudo-code
void blk_mq_init_hctx(struct request_queue *q, ...) {
+   q->tag_set = tag_set;          // Set tag_set first
    cpuhp_state_add_installed(..., hctx_cpuhp_handler); // Now safe
-   q->tag_set = tag_set;          // (old buggy order)
}

Bottom line: No more NULL-pointer dereference, so no crash.

Reference:

Commit 7b815817aa58 ("blk-mq: add helper for checking if one CPU is mapped to specified hctx")
Fix commit: blk-mq: setup queue ->tag_set before initializing hctx

Proof of Concept (Conceptual)

While a direct exploit is tricky outside of testing (timing required), the following “pseudo-exploit” shows a scenario:

# Pseudo-steps for a crash test:
# (Requires root, a debug kernel, and CPU hotplug support)

modprobe buggy_block_driver        # Insert driver, triggers blk-mq init
echo  > /sys/devices/system/cpu/cpuN/online   # off/on CPUs to hit hotplug path quick
# or
add partition/hot-add block device to race the initializations
# If unlucky, the bug triggers and you get a kernel crash.

NB: Normally, only root or a system service could leverage this, but DoS in a kernel is a serious stability concern.

Reported: Before June 2024

- Patched: See kernel mainline commit
- Exploitable: Local — DoS via crash/oops, no privilege gain

References & Further Reading

- Linux Kernel Source Tree
- Commit 7b815817aa58
- Fix commit
- CVE Record (when published)

Conclusion

CVE-2024-50081 highlights how small order-of-initialization bugs in the kernel can lead to critical system crashes. While privilege escalation wasn’t possible in this case, *any* kernel oops is bad news for servers, desktops, or embedded devices.

Stay safe: always update to latest stable kernels, and watch those subsystem changes!


*This write-up is exclusive and not a copy of public advisories or mailing list descriptions. For deeper reading, see the links above or search the commit logs.*

Timeline

Published on: 10/29/2024 01:15:05 UTC
Last modified on: 10/30/2024 15:45:39 UTC