CVE-2024-36978 - Out-of-Bounds Write in Linux Kernel `sch_multiq` Scheduler Explained

A new Linux kernel vulnerability, CVE-2024-36978, has been making waves in recent security bulletins. This issue impacts the network scheduling subsystem (net/sched), specifically in the sch_multiq scheduler implementation. In this post, we'll break down what happened, show you the code involved, explain why it's dangerous, and point you to resources for patching or learning more.

What is the sch_multiq Scheduler?

The Linux kernel uses network “classifiers” and “schedulers” to control how data leaves your system on the network. Among these is sch_multiq, a classful queuing discipline, where each "band" represents a queue for packets.

Core Issue

Inside the function multiq_tune(), the kernel tried to change the number of bands (queues) dynamically. There, an old value for q->bands was mistakenly used instead of the new value just allocated using kmalloc. This meant memory operations could write data out-of-bounds (OOB), leading to a potential system crash or enabling write-what-where conditions.

Why is this bad?
Any OOB write in the kernel space is *critical*. An attacker or buggy user-space program could theoretically trigger this to corrupt kernel memory, escalate privileges, or crash the system.

The Fix

The correct approach is to use the new value qopt->bands (intended band count) when allocating memory, and not rely on the outdated q->bands.

Here's a simplified version of what happened in the kernel code (file: net/sched/sch_multiq.c)

// Old logic before the fix
int multiq_tune(struct Qdisc *sch, struct nlattr *opt, ...) {
    struct multiq_sched_data *q = qdisc_priv(sch);
    struct tc_multiq_qopt *qopt = nla_data(opt);

    // WRONG: using q->bands instead of qopt->bands
    q->queues = kmalloc_array(q->bands, sizeof(struct Qdisc *), GFP_KERNEL);

    // Later, q->bands is changed
    q->bands = qopt->bands;
    ...
}

If the new command provided qopt->bands larger than the old q->bands, memory is incorrectly allocated, and out-of-bounds writes can occur when handling the queues.

With the patch, the code now ensures the allocation uses the new desired number of bands

// Correct logic after the fix
int multiq_tune(struct Qdisc *sch, struct nlattr *opt, ...) {
    struct multiq_sched_data *q = qdisc_priv(sch);
    struct tc_multiq_qopt *qopt = nla_data(opt);

    // CORRECT: allocate with new band count
    q->queues = kmalloc_array(qopt->bands, sizeof(struct Qdisc *), GFP_KERNEL);
    q->bands = qopt->bands;
    ...
}

How Could This Be Exploited?

The attacker (with the ability to call the kernel network scheduler routines, usually requires root or capabilities such as CAP_NET_ADMIN) could:

Trigger allocation using the old, smaller count (before the patch).

3. Cause the kernel to write beyond the allocated memory block (out-of-bounds), corrupting adjacent structures.

Impact ranges from kernel panic (DoS) to potential code execution with kernel privileges. However, this is not remotely exploitable without some privileges on the system.

References and Patch

- Kernel Patch: LKML commit for net: sched: sch_multiq fix
- CVE Record: NVD - CVE-2024-36978
- Fix in Kernel v6.9: Release notes

Protection

- Are you at risk? Only systems with user access to manage network Qdisc are at risk, usually servers or routers with custom traffic shaping setups.
- Mitigation: Update to a Linux kernel version with the patch merged ( kernel >= 6.9.4 or applicable backported vendor patches).
- Detection: Look for attempts to reconfigure sch_multiq with suspicious band values in kernel logs.

Conclusion

While not something every desktop Linux user needs to panic about, CVE-2024-36978 is a strong reminder of the importance of cautious memory management in kernel-space code. Out-of-bounds writes are always dangerous, and in this case, attacking the very heart of how Linux shuffles your packets.

Always keep your systems patched. If you manage a critical Linux server or appliance, check for this update soon.


*This article is for security professionals and Linux administrators. All code examples and explanations are original, simplified for clarity. Consult official resources for deployment details.*

Timeline

Published on: 06/19/2024 07:15:46 UTC
Last modified on: 08/19/2024 18:31:13 UTC