Antrea Integer Overflow: When 65536 Equals 0 (and Admin Rules Don't Matter)

In the world of Kubernetes networking, we trust the CNI (Container Network Interface) to be the immutable arbiter of traffic. You define a NetworkPolicy that says "The database cannot talk to the public internet," and you assume the CNI enforces it. Antrea, a popular CNI based on Open vSwitch (OVS), implements this via a sophisticated Tier system. You have Emergency tiers, SecurityOps tiers, and lowly Application tiers. The hierarchy is absolute. Or so we thought.

CVE-2026-25804 is a reminder that at the end of the day, all your fancy cloud-native logic gets compiled down to basic arithmetic. And in Antrea's case, that arithmetic was confined to a uint16. This vulnerability isn't a complex memory corruption exploit or a race condition; it's a classic integer overflow. It allows a low-privileged user to turn the priority hierarchy upside down, effectively making their application rules more powerful than the cluster admin's emergency lockdowns. It's the digital equivalent of a toddler overuled the Supreme Court because they counted past 10.

The root cause lies in how Antrea translates abstract Policy Tiers into concrete OpenFlow priorities. OpenFlow, the protocol used to program the OVS data plane, uses a 16-bit integer (0-65535) for rule priority. Higher numbers mean higher precedence. Antrea tries to map its logical tiers onto this 16-bit space by calculating 'offsets' from the top of the range.

The logic works like this: Final_Priority = Max_Priority - (Tier_Offset + Policy_Offset + Rule_Offset). Ideally, as you go down the tiers (from Emergency to Application), the offsets get larger, and the Final_Priority gets smaller. This ensures Application rules (low priority) yield to Emergency rules (high priority).

However, the developers performed the addition of these offsets using uint16 arithmetic. If the combined value of the offsets exceeds 65535, it silently wraps around (overflows). Suddenly, a massive offset—which should have resulted in a priority of near-zero—becomes a tiny offset. When you subtract a tiny offset from Max_Priority, you get a massive OpenFlow priority. The odometer rolled over, and the clunker became a Ferrari.

Let's look at the vulnerable code in pkg/agent/controller/networkpolicy/priority.go. It's a textbook example of implicit type casting gone wrong. The developers cast the components to uint16 before adding them, sealing the fate of the calculation.

Vulnerable Code (Before Fix):

// Everything is cast to uint16 immediately
tierOffset := tierOffsetBase * uint16(p.TierPriority)
priorityOffset := uint16(p.PolicyPriority * priorityOffsetBase)
 
// THE BUG: If these sum to > 65535, they wrap around
offSet := tierOffset + priorityOffset + uint16(p.RulePriority)
 
// The check passes because 'offSet' is now a small number due to overflow
if pa.policyTopPriority-pa.policyBottomPriority < offSet {
    return pa.policyBottomPriority
}
 
// Result: A huge priority number (TopPriority - small_number)
return pa.policyTopPriority - offSet

The Fix (Commit 39f21b3b): The patch is straightforward: promote everything to uint32 first, do the math, check for boundaries, and only then cast back to uint16 if it fits.

// Promoted to uint32 to prevent wrap-around
tierOffset := uint32(tierOffsetBase) * uint32(p.TierPriority)
priorityOffset := uint32(p.PolicyPriority * priorityOffsetBase)
offSet := tierOffset + priorityOffset + uint32(p.RulePriority)
 
// Check against the 32-bit calculated offset
availableRange := uint32(pa.policyTopPriority) - uint32(pa.policyBottomPriority)
if availableRange < offSet {
    return pa.policyBottomPriority
}
 
// Now safe to cast back
return pa.policyTopPriority - uint16(offSet)

To exploit this, an attacker doesn't need root access to the node; they just need permission to create NetworkPolicy objects in a namespace (a standard permission for developers). The goal is to force the offSet calculation to hit the magic overflow window (e.g., 65536 or slightly higher).

Step 1: Setup The attacker deploys a malicious pod and creates a NetworkPolicy that allows all traffic (e.g., Allow 0.0.0.0/0). Normally, this would be a low-priority rule residing in the default Application Tier.

Step 2: The Flood The attacker programmatically creates hundreds of dummy NetworkPolicies. Each policy increments the PolicyPriority counter. Antrea's controller dutifully calculates the offset for each one.

Step 3: The Wrap Eventually, the internal calculation tierOffset + priorityOffset + rulePriority hits 65537. In uint16 land, this is 1. The controller calculates the final OpenFlow priority as Max_Priority - 1.

Step 4: Tier Jumping The OVS flow table is updated. The attacker's "Allow All" rule is now inserted at the very top of the table, physically above the admin's "Deny All" rules in the Emergency tier. Traffic that should be blocked is now flowing freely. The attacker has successfully escaped their security tier.

The impact of this vulnerability is high (CVSS 8.0) because it completely undermines the trust model of the network.

1. Security Bypass: Critical segmentation rules (e.g., PCI-DSS boundaries) can be rendered useless without the admin knowing. The dashboard might still show the tiers correctly, but the data plane is doing something entirely different.
2. Denial of Service (DoS): By manipulating priorities, an attacker could invert logic to drop legitimate traffic that should have been allowed.
3. Persistence: Because this is a logic bug in the controller, the incorrect priorities persist until the policies are deleted or the controller is patched. It's a silent failure mode—unless you are actively auditing the raw OpenFlow tables (ovs-ofctl dump-flows), you won't see it.

There is no clever configuration workaround here. You cannot easily restrict the internal math of the controller via config files.

Immediate Action: Upgrade Antrea immediately.

• If you are on 2.3.x, upgrade to 2.3.2.
• If you are on 2.4.x, upgrade to 2.4.3.

Defense in Depth: While patching is the only fix, you should review your Kubernetes RBAC. Why does a single user have the quota to create 500+ NetworkPolicies? Implementing ResourceQuotas on NetworkPolicies per namespace can make exploitation significantly harder (though not impossible, if the attacker compromises multiple namespaces).