CVE-2024-53057 - Use-After-Free in Linux Kernel Traffic Control Queues (TC) — In-Depth Analysis

A recently resolved vulnerability in the Linux kernel, tracked as CVE-2024-53057, is important for everyone running Linux servers and networking devices—from hobbyists to enterprise sysadmins. This is a low-level bug that affects how Linux manages network queues (called "qdiscs"), and it could potentially allow a local attacker to trick the kernel into using memory that’s already been freed (a “use-after-free”, or UAF). This can lead to system crashes, leaks, or even code execution.

What is the Problem? (Explained Simply)

- Location: The bug sits in the Linux kernel’s core networking code, more precisely in qdisc_tree_reduce_backlog() in net/sched/sch_api.c.

What went wrong?

Linux uses objects called *qdiscs* (queueing disciplines) to handle network traffic. Some code wrongly assumed that any qdisc with major handle ffff: must always be a root or ingress (incoming traffic) qdisc—which isn’t true.
Someone could create an “egress” (outgoing) qdisc with that exact handle. When the code works with these, it can accidentally keep pointers (“dangling pointers”) to deleted classes, accidentally using memory *after* it’s been freed (UAF).

Who found it?

Budimir Markovic caught the problem.

Who’s at risk?

Anyone running unpatched Linux kernels with custom qdisc configs, especially those using advanced queuing (like DRR—Deficit Round Robin).

The Vulnerable Code (before)

static void qdisc_tree_reduce_backlog(struct Qdisc *q, ...)
{
    ...
    while (q && TC_H_MAJ(q->handle) == TC_H_MAJ(TC_H_ROOT)) {
        // Assumption: Only root or ingress Qdiscs
        q = q->parent;
    }
}

What's wrong?

The check TC_H_MAJ(q->handle) == TC_H_MAJ(TC_H_ROOT) is not enough. It assumes that having major ffff: must mean you hit the root/ingress. But it’s easy for someone to create a custom qdisc using that major value, tricking the kernel to keep walking up the tree—and hitting freed memory.

The Fixed Code (after patch)

static void qdisc_tree_reduce_backlog(struct Qdisc *q, ...)
{
    ...
    while (q && q->handle != TC_H_ROOT) {
        // Stop when we reach the true root
        q = q->parent;
    }
}

What's fixed?

Now the kernel checks for TC_H_ROOT directly—so it will always stop when hitting the real root, no matter what handles are assigned to custom qdiscs below.

> See the patch for yourself:
> Linux kernel git commit

- A skilled local attacker (someone who can use tc at root or CAP_NET_ADMIN) could

1. Create a custom network queue (qdisc) with major handle ffff:, e.g. using DRR (which tracks active classes in its own list).

Leak: Data could leak through accessing old memory.

- Code execution: With more work, a local attacker could trick the kernel into running attacker-supplied code.

> Note: This is not remotely exploitable, and requires a local user with network admin capabilities. But it’s still a critical bug for multi-tenant, container, and VM environments.

Upgrade your kernel:

- Look for or build a kernel with this commit or higher.

Audit custom qdiscs

- If you use custom/layered queueing set-ups, double check your config or consult your vendor.

Upstream kernel mailing list discussion:

net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT

Fix commit in Linux kernel:

bd61d03f08807e81fcbedddb6b091e930ef6b1b2

CVE entry:

CVE-2024-53057 at Mitre (may update as databases refresh)

Conclusion

CVE-2024-53057 is a great example of how low-level networking assumptions in the Linux kernel can lead to severe issues—even for experienced developers. If you control boxes where users can mess with queueing, update your kernel fast!

Got questions or want to talk kernel bugs? Drop a comment or head over to the kernel mailing list!

Stay safe and updated!

*This post was written in plain language for sysadmins, devs, and anyone interested in Linux kernel security. Share for awareness!*

Timeline

Published on: 11/19/2024 18:15:25 UTC
Last modified on: 12/19/2024 09:38:09 UTC