Repository navigation
kvm: fix security group conntrack NOTRACK optimization for single-direction allow-all rules - #14100
weizhouapache wants to merge 2 commits into
Conversation
…ingle-direction allow-all rule The raw-table NOTRACK rules for a VM IP in the cs_notrack/cs_notrack6 ipsets apply to that IP as both source and destination, disabling connection tracking for it in both directions at once. The check that populates these ipsets did not look at rule['ruletype'], so an allow-all rule in only one direction (e.g. egress all to 0.0.0.0/0) was enough to disable conntrack for the VM, breaking return traffic when the other direction (e.g. ingress) is restricted. Only skip conntrack for a family now when both an ingress allow-all and an egress allow-all rule exist for that family, matching the actual bidirectional effect of the NOTRACK rules.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #14100 +/- ##
============================================
+ Coverage 19.79% 20.39% +0.60%
- Complexity 20020 21283 +1263
============================================
Files 6371 6481 +110
Lines 575954 588040 +12086
Branches 70521 72021 +1500
============================================
+ Hits 114034 119956 +5922
- Misses 449486 455052 +5566
- Partials 12434 13032 +598
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
verified the following cases
|
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Pull request overview
Fixes a security group conntrack optimization bug where a single-direction allow-all rule could incorrectly disable conntrack for both traffic directions on a VM IP.
Changes:
- Track ingress/egress “allow-all” rules separately per IP family (IPv4/IPv6).
- Only disable conntrack (NOTRACK ipset membership) when both ingress and egress are allow-all for a given family.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| ingress4_allow_all = False | ||
| egress4_allow_all = False | ||
| ingress6_allow_all = False | ||
| egress6_allow_all = False |
| if '0.0.0.0/0' in rule['ipv4']: | ||
| if rule['ruletype'] == 'E': | ||
| egress4_allow_all = True | ||
| else: | ||
| ingress4_allow_all = True | ||
| if '::/0' in rule['ipv6']: | ||
| if rule['ruletype'] == 'E': | ||
| egress6_allow_all = True | ||
| else: |
|
Hi @weizhouapache is this PR ready for review or still in progress? |
@nvazquez |
…ss and no egress rules Egress with no rules ends in an unconditional ACCEPT, so it is as open as an explicit allow-all egress rule. Treat it as open when deciding whether the VM IP can be added to the notrack ipset.
|
thanks @Damans227 @vishesh92 |
|
@blueorangutan package |
|
@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
Damans227
left a comment
There was a problem hiding this comment.
thanks @weizhouapache, fix looks right. LGTM
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Copilot review overview
4 open findings
The PR description says conntrack is only skipped when both an ingress allow-all and an egress… · New Theelsebranch treats any non-'E'ruletypeas ingress. Ifruletypeever contains unexpected… The previous block comment explaining why conntrack could be skipped (and the example rule… This boolean accumulation pattern is harder to scan than necessary. Consider using idiomatic… · New
🧠 Review effort: Lite
| # The NOTRACK rules apply to the IP in both directions, so conntrack can only be skipped when | ||
| # ingress allows all and egress is open as well: either an explicit allow-all egress rule or no | ||
| # egress rules at all (the egress chain then accepts everything). | ||
| conntrack4_not_needed = ingress4_allow_all and (egress4_allow_all or not egress4_has_rules) | ||
| conntrack6_not_needed = ingress6_allow_all and (egress6_allow_all or not egress6_has_rules) |
| egress4_has_rules = egress4_has_rules or bool(rule['ipv4']) | ||
| egress6_has_rules = egress6_has_rules or bool(rule['ipv6']) |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19567 |


Description
This PR fixes #14099
The raw-table NOTRACK rules for a VM IP in the cs_notrack/cs_notrack6 ipsets apply to that IP as both source and destination, disabling connection tracking for it in both directions at once. The check that populates these ipsets did not look at rule['ruletype'], so an allow-all rule in only one direction was enough to disable conntrack for the VM.
Connection tracking is needed by the restricted direction: the
ESTABLISHED,RELATEDfallback rules in the VM default chain admit return traffic for connections opened in the other direction. With conntrack disabled they no longer match, so:egress, all, 0.0.0.0/0): responses to connections initiated by the VM are dropped before reaching the tap interface (VMs with security groups allowing all egress traffic cannot access the Internet in 4.23.0.0 #14099);Now a VM IP is added to the notrack ipset for an IP family only when ingress has an explicit allow-all rule (
all,0.0.0.0/0or::/0) and egress is open too, which means either:ACCEPT).cs_notrackbeforecs_notrackafterTypes of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?