CVE-2023-31436 - Out-of-Bounds Write in Linux Kernel qfq_change_class (net/sched/sch_qfq.c)

In the world of Linux kernel vulnerabilities, even a minor miscalculation or unchecked variable can have significant consequences for system stability and security. CVE-2023-31436 is a clear example—a bug in the qfq_change_class function of the Linux kernel's Quick Fair Queueing (QFQ) network scheduler. This vulnerability, present before version 6.2.13, lets attackers trigger an out-of-bounds write via a simple manipulation involving the lmax parameter. Let’s break down how it works, why it happens, and what it means for your system.

Where is the Bug?

The affected code lives in the kernel source at:  
net/sched/sch_qfq.c  
This file implements QFQ, a network scheduler that tries to share bandwidth fairly between different traffic classes.

The vulnerable function is

static int qfq_change_class(struct Qdisc *sch, u32 classid, struct tc_qfq_copt *copt)
{
    struct qfq_sched *q = qdisc_priv(sch);
    struct qfq_class *cl;

    cl = qfq_find_class(q, classid);

    if (!cl)
        return -ENOENT;

    /* ... */
    if (copt) {
        unsigned lmax = copt->lmax;
        /* ... */
        cl->lmax = lmax;
        /* ... */
    }
    /* ... */
    return ;
}

The key issue is with the lmax value. As the Linux kernel commit describes, if lmax is greater than QFQ_MIN_LMAX (65536), internal data structures can be overrun—a classic out-of-bounds write.

Why Does This Happen?

lmax sets the maximum size for a packet. The code expects lmax to stay within a “safe” range (QFQ_MIN_LMAX). But there’s nothing actually checking that the user-supplied value (often coming from netlink or tc commands) respects this limit before using it to allocate arrays or index them. That lack of controls allows a crafty user, even without root, to provide a large lmax and overwrite memory.

Proof-of-Concept (PoC) Overview

An attacker can use a utility such as tc (traffic control) to inject malicious lmax values into the kernel:

# This example assumes you have permissions to load qfq
tc qdisc add dev eth root handle 1: qfq
tc class add dev eth parent 1: classid 1:1 qfq lmax 100000000

With an out-of-bounds lmax, the kernel may overwrite unrelated memory, potentially crashing or corrupting data, or even escalating privileges.

Exploit Details

As of now, no public privilege escalation exploit has been widely circulated, but the risk is clear: kernel out-of-bounds writes are a preferred avenue for local attackers, and past bugs of this kind have been weaponized.

Here’s a simplified illustration of how an attacker might misuse it in C (note: don’t run this on a production machine):

#include <linux/rtnetlink.h>
#include <linux/pkt_sched.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <net/if.h>

// (Omitted: full netlink message construction for brevity)
int main() {
    // Construct a netlink message that adds a qfq class with a huge lmax.
    // This would trigger the vulnerable spot in the kernel.
    // [Here you'd normally use libnl or construct the netlink message by hand]
    printf("Proof of concept - send malicious lmax via netlink\n");
    return ;
}

The real-world exploitation would involve crafting a netlink message (similar to what tc does under the hood) and sending it to the kernel. The effect would vary based on kernel hardening and security configurations (like KASLR, SMEP, etc).

Kernel Patch:

Fix bounds check on lmax in QFQ

Bug Tracker:

CVE-2023-31436 at NVD

Mailing List Discussion:

oss-security: CVE-2023-31436

QFQ Documentation:

Linux QFQ Manpage

How to Fix

Upgrade your kernel as soon as possible.  
All official Linux kernel trees have integrated the patch as of May 2023.

If you maintain a custom kernel, make sure your code checks the upper bound of lmax

unsigned lmax = copt->lmax;
if (lmax > QFQ_MIN_LMAX)
    lmax = QFQ_MIN_LMAX; // Clamp to safe value
cl->lmax = lmax;

Who Is Affected?

Any Linux-based systems running kernels before 6.2.13, using QFQ for traffic control, can be affected. Unprivileged users might not have sufficient permissions to exploit, but privileged (or container-escaped) users could.

Cloud providers, container platforms, and routers that use advanced queueing are most at risk.

Conclusion

CVE-2023-31436 shows how a small oversight in a boundary check can lead to a dangerous kernel bug. If you use network traffic control features in Linux or ship appliances reliant on QFQ, patch now. Out-of-bounds writes are serious and often exploited in the wild.

Always keep your systems updated with the latest security patches.


*Stay safe! For questions or more in-depth technical details, check out the kernel patch or see the official advisory.*

Timeline

Published on: 04/28/2023 02:15:00 UTC
Last modified on: 06/22/2023 15:15:00 UTC