Bug 2074537

Summary: ovn-trace crashes when rejecting ICMP
Product: Red Hat Enterprise Linux Fast Datapath Reporter: François Rigault <frigo>
Component: ovn-2021Assignee: lorenzo bianconi <lorenzo.bianconi>
Status: CLOSED ERRATA QA Contact: Ehsan Elahi <eelahi>
Severity: low Docs Contact:
Priority: unspecified    
Version: RHEL 8.0CC: ctrautma, jiji, lorenzo.bianconi, nusiddiq
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-06-30 18:00:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description François Rigault 2022-04-12 12:43:53 UTC
Description of problem:
- added an ACL like this
ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject

ovn-trace is now crashing.


Version-Release number of selected component (if applicable):
OVN latest from main branch, also from branch 21-12.



How reproducible:
always

Steps to Reproduce:
1.
ovn-nbctl ls-add sw
ovn-nbctl lsp-add sw p1
ovn-nbctl lsp-set-addresses p1 "00:00:00:00:00:02 192.168.0.2"
ovn-nbctl lsp-add sw p2
ovn-nbctl lsp-set-addresses p2 "00:00:00:00:00:03 192.168.0.3"
ovn-nbctl pg-add pg1  p1 p2
ovn-nbctl acl-add pg1 to-lport 2003 "inport==@pg1 && ip4 && ip4.src == 192.168.0.0/16 && udp && udp.dst >= 9000 && udp.dst <= 9999"  allow
ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject

2.
ovn-trace 'inport == "p2" && eth.src == 00:00:00:00:00:03 && eth.dst == 00:00:00:00:00:02 && ip.ttl==42 && ip4.src == 192.168.0.3'

3.

Actual results:
segmentation fault

Expected results:
no segfault

Additional info:
probably same analysis as in
https://bugzilla.redhat.com/show_bug.cgi?id=1934011

We don't add acl directly so I am not sure this is an issue in practice.

Comment 1 Numan Siddique 2022-04-12 14:43:23 UTC
Thanks for raising this bz.  I can see the same crash too.

We recently fixed something similar in ovn-controller - https://github.com/ovn-org/ovn/commit/bcd9a8fb1b60accd6560c45e69ea80b70b2d3346

We should handle something similar in ovn-trace too.

Comment 5 Ehsan Elahi 2022-06-06 22:01:52 UTC
### Reproduced on 
[root@bz-2074537 ~]# rpm -qa |grep -E 'ovn|openvswitch'
openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch
ovn-2021-21.12.0-11.el8fdp.x86_64
ovn-2021-central-21.12.0-11.el8fdp.x86_64
ovn-2021-host-21.12.0-11.el8fdp.x86_64
openvswitch2.15-2.15.0-93.el8fdp.x86_64


systemctl start ovn-northd
ovn-nbctl set-connection ptcp:6641
ovn-sbctl set-connection ptcp:6642
systemctl start openvswitch
ovs-vsctl set open . external_ids:system-id=hv1

# IP address configuration to physical interface
ifconfig ens1f0 42.42.42.1 netmask 255.255.0.0

ovs-vsctl set open . external_ids:ovn-remote=tcp:42.42.42.1:6642
ovs-vsctl set open . external_ids:ovn-encap-type=geneve
ovs-vsctl set open . external_ids:ovn-encap-ip=42.42.42.1
systemctl start ovn-controller

ovn-nbctl ls-add ls1
ovn-nbctl lsp-add ls1 ls1p1
ovn-nbctl lsp-set-addresses ls1p1 "00:00:00:00:00:01 42.42.42.1"
ovn-nbctl lsp-add ls1 ls1p2
ovn-nbctl lsp-set-addresses ls1p2 "00:00:00:00:00:02 42.42.42.2"

ovn-nbctl pg-add pg1  ls1p1 ls1p2
ovn-nbctl acl-add pg1 to-lport 2003 "inport==@pg1 && ip4 && ip4.src == 42.42.42.0/24 && udp && udp.dst >= 9000 && udp.dst <= 9999"  allow
ovn-nbctl acl-add pg1 to-lport 2001 "inport==@pg1" reject

[root@bz-2074537 ~]# ovn-trace 'inport == "ls1p2" && eth.src == 00:00:00:00:00:02 && eth.dst == 00:00:00:00:00:01 && ip.ttl==42 && ip4.src == 42.42.42.2'
Segmentation fault (core dumped)

### Verified on 
[root@bz-2074537 ~]# rpm -qa |grep -E 'ovn|openvswitch'
openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch
ovn-2021-21.12.0-73.el8fdp.x86_64
ovn-2021-central-21.12.0-73.el8fdp.x86_64
ovn-2021-host-21.12.0-73.el8fdp.x86_64
openvswitch2.15-2.15.0-93.el8fdp.x86_64

[root@bz-2074537 ~]# ovn-trace 'inport == "ls1p2" && eth.src == 00:00:00:00:00:02 && eth.dst == 00:00:00:00:00:01 && ip.ttl==42 && ip4.src == 42.42.42.2'
# ip,reg14=0x2,vlan_tci=0x0000,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,nw_src=42.42.42.2,nw_dst=0.0.0.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=42

ingress(dp="ls1", inport="ls1p2")
---------------------------------
 0. ls_in_port_sec_l2 (northd.c:5597): inport == "ls1p2", priority 50, uuid de255dec
    next;
24. ls_in_l2_lkup (northd.c:8454): eth.dst == 00:00:00:00:00:01, priority 50, uuid 182c8727
    outport = "ls1p1";
    output;

egress(dp="ls1", inport="ls1p2", outport="ls1p1")
-------------------------------------------------
 4. ls_out_acl (northd.c:6277): inport==@pg1, priority 3001, uuid 66b3def3
    reg0 = 0;
    reject { outport <-> inport; next(pipeline=ingress, table=24); };

icmp4
-----
    outport <-> inport;
    next(pipeline=ingress, table=24);

ingress(dp="ls1", inport="ls1p1")
---------------------------------
24. ls_in_l2_lkup (northd.c:8454): eth.dst == 00:00:00:00:00:02, priority 50, uuid 8211896b
    outport = "ls1p2";
    output;

egress(dp="ls1", inport="ls1p1", outport="ls1p2")
-------------------------------------------------
 4. ls_out_acl (northd.c:6277): inport==@pg1, priority 3001, uuid 66b3def3
    reg0 = 0;
    reject { outport <-> inport; next(pipeline=ingress, table=24); };

Comment 6 Ehsan Elahi 2022-06-07 12:37:27 UTC
###Also verified on 

[root@bz-2074537 ~]# rpm -qa |grep -E 'ovn|openvswitch'
 openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch
 ovn22.03-22.03.0-52.el8fdp.x86_64
 ovn22.03-host-22.03.0-52.el8fdp.x86_64
 openvswitch2.15-2.15.0-93.el8fdp.x86_64
 ovn22.03-central-22.03.0-52.el8fdp.x86_64

###And verified on

[root@bz-2074537 ~]# rpm -qa |grep -E 'ovn|openvswitch'
openvswitch-selinux-extra-policy-1.0-31.el9fdp.noarch
openvswitch2.16-2.16.0-52.el9fdp.x86_64
ovn22.03-22.03.0-52.el9fdp.x86_64
ovn22.03-central-22.03.0-52.el9fdp.x86_64
ovn22.03-host-22.03.0-52.el9fdp.x86_64

Comment 8 errata-xmlrpc 2022-06-30 18:00:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (ovn bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:5446