fix ref leak when switching zones
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| linux-bluefield (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
| Focal |
Fix Released
|
Medium
|
Bodong Wang | ||
Bug Description
* Explain the bug(s)
When switching zones or network namespaces without doing a ct clear in
between, it is now leaking a reference to the old ct entry. That's
because tcf_ct_
tcf_ct_
The fix is to, as the ct entry is not reusable, free it already at
tcf_ct_
* brief explanation of fixes
The fix is to, as the ct entry is not reusable, free it already at
tcf_ct_
* How to test
Setup ovs with ovs offload enabled on veth or other software only devices (so it will
only be offloaded to TC and not also to HW which will take longer), example:
function config_veth() {
local ns=$1
local ip=$2
local peer=${ns}_peer
local veth=${ns}_veth
echo "Create namespace $ns, veths: hv $veth <-> ns $peer ($ip)"
ip netns add $ns
ip link del $veth &>/dev/null
ip link add $veth type veth peer name $peer
ip link set $veth up
ip link set $peer netns $ns
ip netns exec $ns ifconfig $peer $ip/24 mtu 1400 up
}
IP1="7.7.7.1"
IP2="7.7.7.2"
config_veth ns0 $IP1
config_veth ns1 $IP2
ovs-vsctl add-br ovs-br
ovs-vsctl add-port ovs-br ns0_veth
ovs-vsctl add-port ovs-br ns1_veth
Add openflow rules configuring two or more chained zones, example:
function configure_rules() {
local orig_dev=$1
local reply_dev=$2
ovs-ofctl del-flows ovs-br
ovs-ofctl add-flow ovs-br "table=0, arp, actions=normal"
#ORIG
ovs-ofctl add-flow ovs-br "table=0, ip,in_port=
ovs-ofctl add-flow ovs-br "table=5, ip,in_port=
ovs-ofctl add-flow ovs-br "table=5, ip,in_port=
ovs-ofctl add-flow ovs-br "table=7, ip,in_port=
ovs-ofctl add-flow ovs-br "table=7, ip,in_port=
#REPLY
ovs-ofctl add-flow ovs-br "table=0, ip,in_port=
ovs-ofctl add-flow ovs-br "table=8, ip,in_port=
ovs-ofctl add-flow ovs-br "table=9, ip,in_port=
ovs-ofctl dump-flows ovs-br --color
}
configure_rules veth1 veth2
run udp/tcp traffic from veth1 to veth2 such that it will pass both zones in the resuling tc rules,
and check conntrack dying table after ending traffic:
conntrack -L dying
If bug occurs, dying table won't be empty and will have entries with refcount > 0:
tcp 6 0 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=47180 dport=6538 src=127.0.0.1 dst=127.0.0.1 sport=6538 dport=47180 ... mark=0 use=2
* What it could break.
Reaching full conntrack table and then dropping packets
CVE References
| Changed in linux-bluefield (Ubuntu Focal): | |
| assignee: | nobody → Bodong Wang (bodong-wang) |
| importance: | Undecided → Medium |
| status: | New → In Progress |
| Changed in linux-bluefield (Ubuntu): | |
| status: | New → Invalid |
| Changed in linux-bluefield (Ubuntu Focal): | |
| status: | In Progress → Fix Committed |
| Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote | #1 |
| tags: | added: verification-needed-focal |
| Launchpad Janitor (janitor) wrote | #2 |
| Changed in linux-bluefield (Ubuntu Focal): | |
| status: | Fix Committed → Fix Released |
This bug is awaiting verification that the linux-bluefield
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.
See https:/