CVE-2025-21692 - Out-of-Bounds ETS Class Indexing in Linux Kernel Can Lead to Local Privilege Escalation

A serious vulnerability tracked as CVE-2025-21692 was discovered in the Linux kernel’s network scheduler subsystem, specifically in the ETS (Enhanced Transmission Selection) queuing discipline. The issue was reported by Haowei Yan and affects the ets_class_from_arg() function, which could allow a local attacker to escalate privileges due to an out-of-bounds array access.

This post aims to clearly explain what the bug is, how it can be exploited, code pointers to the root cause, and how to protect your systems.

Background: What is ETS?

The Linux kernel uses "qdiscs" (queueing disciplines) to manage how packets are handled and scheduled for transmission. ETS is one such scheduler that implements different queueing strategies for network traffic.

Vulnerability Details

The vulnerability lies in how the kernel handles the clid (class id) parameter in ets_class_from_arg(). If a user passes a class id (clid) of , the function mistakenly tries to access an out-of-bounds element in the ets_class array, leading to a situation where arbitrary kernel memory can be read or written, depending on how the compiler has laid out memory. With clever exploitation, this can give the attacker escalated privileges.

When the bug is triggered, you might see logs like

UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20
index 18446744073709551615 is out of range for type 'ets_class [16]'

Note: The index value is -1 interpreted as unsigned, which usually happens if you do something like clid - 1 where clid is zero.

Here’s a simplified version of the vulnerable function in net/sched/sch_ets.c

// ets_class_from_arg expects clid in [1, TC_ETS_MAX] (typically 16)
static inline struct ets_class *ets_class_from_arg(struct Qdisc *sch, u32 clid)
{
    struct ets_sched_data *q = qdisc_priv(sch);
    // The following line is dangerous when clid == 
    return clid ? &q->classes[clid - 1] : NULL;
}

If clid is , then clid - 1 becomes -1, which for an unsigned type (like array indices) becomes 18446744073709551615. Accessing q->classes[-1] is an out-of-bounds access.

Proof-of-Concept: Trigger the Bug Locally

An attacker with *CAP_NET_ADMIN* privileges (which unprivileged users may be able to gain in container or cloud environments) can exploit this by manually triggering a class change with a clid of . Here’s a simple PoC using the tc tool:

# Prepare a network interface (e.g., create a veth pair or use loopback)
sudo tc qdisc add dev lo root ets

# Trigger the bug by attempting to change class id 
sudo tc class change dev lo classid : ets

After running this, your dmesg should show the out-of-bounds error message. A tailored exploit could use this to read or write kernel memory.

Exploit Impact

- Local privilege escalation: Since the function operates in kernel context, corrupting struct ets_class or adjacent memory structures could allow an attacker to gain arbitrary code execution in the kernel.

The Fix

Fixed in Linux 6.7:
The patch simply makes sure clid is validated before accessing the array. The maintainers now bail out if clid is out of range.

if (!clid || clid > TC_ETS_MAX)
    return NULL;
return &q->classes[clid - 1];

So, passing in a clid of or any value outside the allowed range no longer causes an out-of-bounds access.

References

- Upstream Linux fix (commit)
- Ubuntu Security Notice *(replace XXXX with real number when available)*
- Kernel Mailing List Patch Discussion

Recommended Actions

- Update your Linux kernel to v6.7 or later (or if your distribution has backported the fix, apply all security updates).
- For kernel programmers: Always validate any user-supplied input, especially if it will be used to index arrays or touch memory.

Conclusion

CVE-2025-21692 reminds us that even very advanced kernel code can have simple bugs with big impacts. Out-of-bounds array accesses are a classic and dangerous class of bug. Always keep your systems up to date, follow best practices in validating input, and support a responsible disclosure process.

Timeline

Published on: 02/10/2025 16:15:38 UTC
Last modified on: 03/24/2025 15:38:58 UTC