CVE-2023-4208 - How a Use-After-Free in Linux Kernel’s cls_u32 Can Lead to Root

CVE-2023-4208 is a dangerous use-after-free vulnerability in the Linux kernel's traffic control filter subsystem, specifically in net/sched: cls_u32. This issue affects multiple Linux distributions and can be leveraged by a local attacker to gain root privileges. This long read explains the bug in plain English, walks through the exploitation opportunities, shows you simplified source code snippets, and summarizes mitigation.


## What is net/sched: cls_u32?

cls_u32 is a flexible classifier module in the Linux network stack, letting system administrators and programs match packets for shaping, marking, or filtering traffic. If you have ever used tc to set up Quality of Service (QoS) or firewall rules at an advanced level, you have likely touched cls_u32.

Vulnerable Function

The root of this bug is in how the filter update happens, specifically in the function u32_change().

Vulnerable Flow

- When you update a filter (using u32_change()), the kernel copies the entire tcf_result struct from the old filter to the new one.
- TCF (Traffic Control Filter) can be linked to *classes*, such as a particular traffic queue or priority setup.
- When the old filter is replaced, tcf_unbind_filter() is called on the old filter *even though* the copied-over reference (still pointing to the class) was just handed to the new filter — which is not safe.

The Problem

Calling tcf_unbind_filter() decreases the filter's reference count in the class, even though the new filter still references the same class. If this class's reference count now reaches zero, the system can delete it — but the new filter still thinks it has a valid pointer.

This leads straight to a use-after-free, where the kernel holds a dangling pointer to freed memory, and a clever user can now *reuse* that memory block.

Exploit Details: Achieving Privilege Escalation

This bug is powerful because it lets local users manipulate kernel memory, usually leading to full system compromise.

Update the filter using tc to trigger the copying bug.

3. Spray memory (e.g., with other kernel objects) so the freed class structure gets reused and filled with controlled data.
4. When the kernel later accesses the freed class via the copied pointer, attacker-controlled data can be executed — possibly escalating privileges or even executing code in kernel context.

Example Exploit Primitives

One possible route is to overwrite key function pointers in the now-freed structure, leading to arbitrary code execution as root. Since the attacker controls the timing, and the reference to the class can be repeatedly dereferenced, exploitation is reliable.

Let's look at a simplified version to illustrate the flow

// tcf_result struct
struct tcf_result {
    // ...
    void *class; // pointer to class object
    // ...
};

// In u32_change(), update filter:
new_filter->res = old_filter->res; // Copies tcf_result, including .class

// Later on:
tcf_unbind_filter(old_filter->res.class); // Decrement refcount, possible free

// new_filter->res.class is now a use-after-free pointer!

Key problem

new_filter->res.class still points to freed memory.

Patch and Mitigation

The fix is relatively straightforward: avoid copying the raw pointer from the old tcf_result to the new one, or make sure reference counting and memory management preserve the lifetime until all users are gone.

Patched in commit:

3044b16e7c6fe5d24b1cdbcf1bda9d92d1ebd81

Upstream commit discussion:

https://lore.kernel.org/lkml/20230823173148.3648-1-xyz@kernel.org/

CVE details:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4208

Red Hat Security advisory:

https://access.redhat.com/security/cve/CVE-2023-4208

It can lead to local privilege escalation (root access).

- All system administrators should update their kernels past commit 3044b16e7c6fe5d24b1cdbcf1bda9d92d1ebd81 today!

Stay safe, and keep your kernels patched!

*This technical breakdown is an original and exclusive explanation tailored for simplicity and clarity. For more in-depth analysis of kernel vulnerabilities, keep following our blog!*

Timeline

Published on: 09/06/2023 14:15:11 UTC
Last modified on: 09/11/2023 18:12:56 UTC