Invalid OF priority assignments when stress testing ANP implementation

bug_report.md

Describe the bug Antrea's network policy priority assignment system has a uint16 arithmetic overflow bug that causes incorrect OpenFlow priority calculations when handling a large numbers of policies with various priority values. This results in potentially incorrect traffic enforcement.

The bug occurs in the initialOFPriority() function in pkg/agent/controller/networkpolicy/priority.go when calculating the offset for policies with higher priority values. The arithmetic overflow causes policies with higher numerical priorities to receive incorrect (and sometimes higher) OpenFlow priorities than policies with lower numerical priorities, violating the expected priority ordering.

To Reproduce

1. Create 300 Antrea Network Policies with increasing priorities from 1.0 to 300.0 in the default tier (priority 250)
2. Register all priorities with the priority assigner
3. Check the OpenFlow priorities assigned to policies with different priority values
4. Observe that policy priority 1.0 gets OpenFlow priority 14900, while policy priority 249.0 gets OpenFlow priority 55636 (higher than priority 1.0)

Unit test to reproduce

func TestRegister300PrioritiesOrdering(t *testing.T) {
    pa := newPriorityAssigner(false)
    
    // Create 300 priorities with increasing policy priorities from 1.0 to 300.0
    var priorities []types.Priority
    for i := 1; i <= 300; i++ {
        priority := types.Priority{
            TierPriority:   defaultTierPriority, // 250
            PolicyPriority: float64(i),          
            RulePriority:   0,                   
        }
        priorities = append(priorities, priority)
    }
    
    _, _, err := pa.registerPriorities(priorities)
    assert.NoError(t, err)
    
    // This will fail due to the bug
    priority1 := types.Priority{TierPriority: defaultTierPriority, PolicyPriority: 1.0, RulePriority: 0}
    priority249 := types.Priority{TierPriority: defaultTierPriority, PolicyPriority: 249.0, RulePriority: 0}
    
    ofPriority1, _ := pa.getOFPriority(priority1)
    ofPriority249, _ := pa.getOFPriority(priority249)
    
    assert.Greater(t, ofPriority1, ofPriority249) // FAILS: 14900 > 55636
}

Expected

• Policy priority 1.0 should receive a higher OpenFlow priority (larger numerical value) than policy priority 249.0
• All policies should maintain correct priority ordering: lower policy priority values should get higher OpenFlow priorities

Actual behavior

• Policy priority 1.0 → OpenFlow priority 14900
• Policy priority 249.0 → OpenFlow priority 55636 (incorrectly higher than priority 1.0)
• Policy priority 300.0 → OpenFlow priority 50536

Priority ordering is broken for policies with higher numerical priorities

Versions: Antrea: current main branch

Additional context The documentation recommends using priority values within the range 1.0 to 100.0. As long as this advice is followed, the implementation should behave correctly. However, also according to the same document, priority values can range from 1.0 to 10000.0 and we support up to 10,000 unique policy priorities. Hence this is an actual bug that needs to be fixed.

Unit testing should be improved to cover the full range of supported priority values, and to validate that the OpenFlow priority assignment is correct.

Note that a similar issue was observed after an Agent restart, so both cases (incremental policy creation and restart) should be covered, assuming the code paths are different.