This bug was fixed in the package linux-bluefield - 5.4.0-1062.68
---------------
linux-bluefield (5.4.0-1062.68) focal; urgency=medium
* focal/linux-bluefield: 5.4.0-1062.68 -proposed tracker (LP:
#2016751)
* CVE-2023-1829
- [Config] bluefield: Make sure CONFIG_NET_CLS_TCINDEX is not available
* net/sched: cls_api: Support hardware miss to tc action (LP: #2012571)
- Revert "net/sched: flower: fix fl_change() error recovery path"
- Revert "net/sched: flower: Support hardware miss to tc action"
- Revert "net/sched: flower: Move filter handle initialization earlier"
- Revert "net/sched: cls_api: Support hardware miss to tc action"
- Revert "UBUNTU: SAUCE: net/sched: Provide act to offload action"
[ Ubuntu: 5.4.0-148.165 ]
* focal/linux: 5.4.0-148.165 -proposed tracker (LP: #2016777)
* CVE-2023-1829
- net/sched: Retire tcindex classifier
- [Config]: Make sure CONFIG_NET_CLS_TCINDEX is not available
-- Bartlomiej Zolnierkiewicz <[email protected]>
Thu, 27 Apr 2023 16:48:23 +0200
** Changed in: linux-bluefield (Ubuntu Focal)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-1829
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/2012571
Title:
net/sched: cls_api: Support hardware miss to tc action
Status in linux-bluefield package in Ubuntu:
Invalid
Status in linux-bluefield source package in Focal:
Fix Released
Bug description:
* Explain the bug(s)
Currently tc miss interface only supports resuming from a specific tc chain.
If a packet modification is done before a missable action such as CT and
there is a miss in CT after it, this may cause a miss match when resuming
re-executing the same chain in software, and wrong packet count.
This use case for example is a stateless (static) nat.
* brief explanation of fixes
Add support for missing to a specific action instance, and support
of per action hardware stats to update what was actually done in hardware.
* How to test
Create OVS bridge with 2 devices mlx5 rep devices.
Enable HW offload and configure regular connection tracking OpenFlow rules
with packet modification before the CT action (such as statless nat):
e.g:
ovs-ofctl del-flows br-ovs
ovs-ofctl add-flow br-ovs arp,actions=normal
ovs-ofctl add-flow br-ovs "in_port=1,table=0, ip,ct_state=-trk
actions=mod_nw_dst=1.1.1.2,ct(table=1)"
ovs-ofctl add-flow br-ovs "in_port=1,table=1, ip,ct_state=+trk+new
actions=ct(commit),output:2"
ovs-ofctl add-flow br-ovs "in_port=1,table=1, ip,ct_state=+trk+est,
actions=output:2"
ovs-ofctl add-flow br-ovs "in_port=2,table=0, ip,ct_state=-trk
actions=ct(table=1)"
ovs-ofctl add-flow br-ovs "in_port=2,table=1, ip,ct_state=+trk+est,
actions=mod_nw_src=1.1.1.2,output:1"
Config VF1 ip 1.1.1.1, VF2 ip 1.1.1.2
For VF2, add route and static neighbour to floating (router) ip
5.5.5.5
Then run a TCP connection, e.g:
on mlx5 VF1 iperf -s #(which will listen on 1.1.1.2)
on mlx5 VF2 iperf -c 5.5.5.5 -t 10 #(this creates a packet from 1.1.1.1 ->
5.5.5.5, and nat will change this to 1.1.1.1->1.1.1.2)
Optional: In different terminal, while traffic is running, check for offload:
tcpdump -nnepi <RELEVANT_MLX5_REP> tcp
and see no iperf tcp packets.
Dump conntrack with relevant ip:
cat /proc/net/nf_conntrack | grep -i 1.1.1.1
See tuples were offloaded:
ipv4 2 tcp 6 src= 1.1.1.1 dst=1.1.1.2 sport=56394 dport=5001
packets=2 bytes=112 src=1.1.1.2 dst=1.1.1.1 sport=5001 dport=56394 packets=1777
bytes=665340 [HW_OFFLOAD] mark=0 zone=0 use=3
* What it could break.
offload for modifications + ct and tc packet count.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2012571/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
