ebpf throughput is 3-4 times slower #13
Comments
|
there is a bug that doesn't clear CT fields in bpf_flow_key. ebpf throughput is good after fixing this bug. |
williamtu
pushed a commit
that referenced
this issue
Jul 31, 2019
The following, run inside the OVS sandbox, caused OVS to abort when
Address Sanitizer was used:
ovs-vsctl add-br br-int
ovs-ofctl add-flow br-int "table=0,cookie=0x1234,priority=10000,icmp,actions=drop"
ovs-ofctl --strict del-flows br-int "table=0,cookie=0x1234/-1,priority=10000"
Sample report from Address Sanitizer:
==3029==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000043260 at pc 0x7f6b09c2459b bp 0x7ffcb67e7540 sp 0x7ffcb67e6cf0
READ of size 40 at 0x603000043260 thread T0
#0 0x7f6b09c2459a (/lib/x86_64-linux-gnu/libasan.so.5+0xb859a)
#1 0x565110a748a5 in minimask_equal ../lib/flow.c:3510
#2 0x565110a9ea41 in minimatch_equal ../lib/match.c:1821
#3 0x56511091e864 in collect_rules_strict ../ofproto/ofproto.c:4516
#4 0x56511093d526 in delete_flow_start_strict ../ofproto/ofproto.c:5959
#5 0x56511093d526 in ofproto_flow_mod_start ../ofproto/ofproto.c:7949
#6 0x56511093d77b in handle_flow_mod__ ../ofproto/ofproto.c:6122
#7 0x56511093db71 in handle_flow_mod ../ofproto/ofproto.c:6099
#8 0x5651109407f6 in handle_single_part_openflow ../ofproto/ofproto.c:8406
#9 0x5651109407f6 in handle_openflow ../ofproto/ofproto.c:8587
#10 0x5651109e40da in ofconn_run ../ofproto/connmgr.c:1318
#11 0x5651109e40da in connmgr_run ../ofproto/connmgr.c:355
#12 0x56511092b129 in ofproto_run ../ofproto/ofproto.c:1826
#13 0x5651108f23cd in bridge_run__ ../vswitchd/bridge.c:2965
#14 0x565110904887 in bridge_run ../vswitchd/bridge.c:3023
#15 0x5651108e659c in main ../vswitchd/ovs-vswitchd.c:127
#16 0x7f6b093b709a in __libc_start_main ../csu/libc-start.c:308
#17 0x5651108e9009 in _start (/home/blp/nicira/ovs/_build/vswitchd/ovs-vswitchd+0x11d009)
This fixes the problem, which although largely theoretical could crop up
with odd implementations of memcmp(), perhaps ones optimized in various
"clever" ways. All in all, it seems best to avoid the theoretical problem.
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
PlumeTomi
pushed a commit
to PlumeTomi/ovs-ebpf
that referenced
this issue
Oct 8, 2020
Should use flow->actions not &flow->actions.
here is ASAN report:
=================================================================
==57189==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xffff428fa0e8 at pc 0xffff7f61a520 bp 0xffff428f9420 sp 0xffff428f9498 READ of size 196 at 0xffff428fa0e8 thread T150 (revalidator22)
#0 0xffff7f61a51f in __interceptor_memcpy (/lib64/libasan.so.4+0xa251f)
williamtu#1 0xaaaad26a3b2b in ofpbuf_put lib/ofpbuf.c:426
williamtu#2 0xaaaad26a30cb in ofpbuf_clone_data_with_headroom lib/ofpbuf.c:248
williamtu#3 0xaaaad26a2e77 in ofpbuf_clone_with_headroom lib/ofpbuf.c:218
williamtu#4 0xaaaad26a2dc3 in ofpbuf_clone lib/ofpbuf.c:208
williamtu#5 0xaaaad23e3993 in ukey_set_actions ofproto/ofproto-dpif-upcall.c:1640
williamtu#6 0xaaaad23e3f03 in ukey_create__ ofproto/ofproto-dpif-upcall.c:1696
williamtu#7 0xaaaad23e553f in ukey_create_from_dpif_flow ofproto/ofproto-dpif-upcall.c:1806
williamtu#8 0xaaaad23e65fb in ukey_acquire ofproto/ofproto-dpif-upcall.c:1984
williamtu#9 0xaaaad23eb583 in revalidate ofproto/ofproto-dpif-upcall.c:2625
williamtu#10 0xaaaad23dee5f in udpif_revalidator ofproto/ofproto-dpif-upcall.c:1076
williamtu#11 0xaaaad26b84ef in ovsthread_wrapper lib/ovs-thread.c:708
williamtu#12 0xffff7e74a8bb in start_thread (/lib64/libpthread.so.0+0x78bb)
williamtu#13 0xffff7e0665cb in thread_start (/lib64/libc.so.6+0xd55cb)
Address 0xffff428fa0e8 is located in stack of thread T150 (revalidator22) at offset 328 in frame
#0 0xaaaad23e4cab in ukey_create_from_dpif_flow ofproto/ofproto-dpif-upcall.c:1762
This frame has 4 object(s):
[32, 96) 'actions'
[128, 192) 'buf'
[224, 328) 'full_flow'
[384, 2432) 'stub' <== Memory access at offset 328 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported) Thread T150 (revalidator22) created by T0 here:
#0 0xffff7f5b0f7f in __interceptor_pthread_create (/lib64/libasan.so.4+0x38f7f)
williamtu#1 0xaaaad26b891f in ovs_thread_create lib/ovs-thread.c:792
williamtu#2 0xaaaad23dc62f in udpif_start_threads ofproto/ofproto-dpif-upcall.c:639
williamtu#3 0xaaaad23daf87 in ofproto_set_flow_table ofproto/ofproto-dpif-upcall.c:446
williamtu#4 0xaaaad230ff7f in dpdk_evs_cfg_set vswitchd/bridge.c:1134
williamtu#5 0xaaaad2310097 in bridge_reconfigure vswitchd/bridge.c:1148
williamtu#6 0xaaaad23279d7 in bridge_run vswitchd/bridge.c:3944
williamtu#7 0xaaaad23365a3 in main vswitchd/ovs-vswitchd.c:240
williamtu#8 0xffff7dfb1adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
williamtu#9 0xaaaad230a3d3 (/usr/sbin/ovs-vswitchd-2.7.0-1.1.RC5.001.asan+0x26f3d3)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.4+0xa251f) in __interceptor_memcpy Shadow bytes around the buggy address:
0x200fe851f3c0: 00 00 00 00 f1 f1 f1 f1 f8 f2 f2 f2 00 00 00 00
0x200fe851f3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f3f0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
0x200fe851f400: f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2
=>0x200fe851f410: 00 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2
0x200fe851f420: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==57189==ABORTING
Acked-by: Numan Siddique <numans@ovn.org>
Signed-off-by: Linhaifeng <haifeng.lin@huawei.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
PlumeTomi
pushed a commit
to PlumeTomi/ovs-ebpf
that referenced
this issue
Aug 8, 2021
Should use flow->actions not &flow->actions.
here is ASAN report:
=================================================================
==57189==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xffff428fa0e8 at pc 0xffff7f61a520 bp 0xffff428f9420 sp 0xffff428f9498 READ of size 196 at 0xffff428fa0e8 thread T150 (revalidator22)
#0 0xffff7f61a51f in __interceptor_memcpy (/lib64/libasan.so.4+0xa251f)
williamtu#1 0xaaaad26a3b2b in ofpbuf_put lib/ofpbuf.c:426
williamtu#2 0xaaaad26a30cb in ofpbuf_clone_data_with_headroom lib/ofpbuf.c:248
williamtu#3 0xaaaad26a2e77 in ofpbuf_clone_with_headroom lib/ofpbuf.c:218
williamtu#4 0xaaaad26a2dc3 in ofpbuf_clone lib/ofpbuf.c:208
williamtu#5 0xaaaad23e3993 in ukey_set_actions ofproto/ofproto-dpif-upcall.c:1640
williamtu#6 0xaaaad23e3f03 in ukey_create__ ofproto/ofproto-dpif-upcall.c:1696
williamtu#7 0xaaaad23e553f in ukey_create_from_dpif_flow ofproto/ofproto-dpif-upcall.c:1806
williamtu#8 0xaaaad23e65fb in ukey_acquire ofproto/ofproto-dpif-upcall.c:1984
williamtu#9 0xaaaad23eb583 in revalidate ofproto/ofproto-dpif-upcall.c:2625
williamtu#10 0xaaaad23dee5f in udpif_revalidator ofproto/ofproto-dpif-upcall.c:1076
williamtu#11 0xaaaad26b84ef in ovsthread_wrapper lib/ovs-thread.c:708
williamtu#12 0xffff7e74a8bb in start_thread (/lib64/libpthread.so.0+0x78bb)
williamtu#13 0xffff7e0665cb in thread_start (/lib64/libc.so.6+0xd55cb)
Address 0xffff428fa0e8 is located in stack of thread T150 (revalidator22) at offset 328 in frame
#0 0xaaaad23e4cab in ukey_create_from_dpif_flow ofproto/ofproto-dpif-upcall.c:1762
This frame has 4 object(s):
[32, 96) 'actions'
[128, 192) 'buf'
[224, 328) 'full_flow'
[384, 2432) 'stub' <== Memory access at offset 328 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported) Thread T150 (revalidator22) created by T0 here:
#0 0xffff7f5b0f7f in __interceptor_pthread_create (/lib64/libasan.so.4+0x38f7f)
williamtu#1 0xaaaad26b891f in ovs_thread_create lib/ovs-thread.c:792
williamtu#2 0xaaaad23dc62f in udpif_start_threads ofproto/ofproto-dpif-upcall.c:639
williamtu#3 0xaaaad23daf87 in ofproto_set_flow_table ofproto/ofproto-dpif-upcall.c:446
williamtu#4 0xaaaad230ff7f in dpdk_evs_cfg_set vswitchd/bridge.c:1134
williamtu#5 0xaaaad2310097 in bridge_reconfigure vswitchd/bridge.c:1148
williamtu#6 0xaaaad23279d7 in bridge_run vswitchd/bridge.c:3944
williamtu#7 0xaaaad23365a3 in main vswitchd/ovs-vswitchd.c:240
williamtu#8 0xffff7dfb1adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
williamtu#9 0xaaaad230a3d3 (/usr/sbin/ovs-vswitchd-2.7.0-1.1.RC5.001.asan+0x26f3d3)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.4+0xa251f) in __interceptor_memcpy Shadow bytes around the buggy address:
0x200fe851f3c0: 00 00 00 00 f1 f1 f1 f1 f8 f2 f2 f2 00 00 00 00
0x200fe851f3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f3f0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
0x200fe851f400: f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2
=>0x200fe851f410: 00 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2
0x200fe851f420: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200fe851f460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==57189==ABORTING
Acked-by: Numan Siddique <numans@ovn.org>
Signed-off-by: Linhaifeng <haifeng.lin@huawei.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
PlumeTomi
pushed a commit
to PlumeTomi/ovs-ebpf
that referenced
this issue
Aug 8, 2021
OVS uses memcmp to compare actions of existing and new flows, but
'struct ofp_ed_prop_nsh_md_type' and corresponding ofpact structure has
3 bytes of padding that never initialized and passed around within OF
data structures and messages.
Uninitialized bytes in MemcmpInterceptorCommon
at offset 21 inside [0x7090000003f8, 136)
WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x4a184e in bcmp (vswitchd/ovs-vswitchd+0x4a184e)
williamtu#1 0x896c8a in ofpacts_equal lib/ofp-actions.c:9121:31
williamtu#2 0x564403 in replace_rule_finish ofproto/ofproto.c:5650:37
williamtu#3 0x563462 in add_flow_finish ofproto/ofproto.c:5218:13
williamtu#4 0x54a1ff in ofproto_flow_mod_finish ofproto/ofproto.c:8091:17
williamtu#5 0x5433b2 in handle_flow_mod__ ofproto/ofproto.c:6216:17
williamtu#6 0x56a2fc in handle_flow_mod ofproto/ofproto.c:6190:17
williamtu#7 0x565bda in handle_single_part_openflow ofproto/ofproto.c:8504:16
williamtu#8 0x540b25 in handle_openflow ofproto/ofproto.c:8685:21
williamtu#9 0x6697fd in ofconn_run ofproto/connmgr.c:1329:13
williamtu#10 0x668e6e in connmgr_run ofproto/connmgr.c:356:9
williamtu#11 0x53f1bc in ofproto_run ofproto/ofproto.c:1890:5
williamtu#12 0x4ead0c in bridge_run__ vswitchd/bridge.c:3250:9
williamtu#13 0x4e9bc8 in bridge_run vswitchd/bridge.c:3309:5
williamtu#14 0x51c072 in main vswitchd/ovs-vswitchd.c:127:9
williamtu#15 0x7f23a99011a2 in __libc_start_main (/lib64/libc.so.6)
williamtu#16 0x46b92d in _start (vswitchd/ovs-vswitchd+0x46b92d)
Uninitialized value was stored to memory at
#0 0x4745aa in __msan_memcpy.part.0 (vswitchd/ovs-vswitchd)
williamtu#1 0x54529f in rule_actions_create ofproto/ofproto.c:3134:5
williamtu#2 0x54915e in ofproto_rule_create ofproto/ofproto.c:5284:11
williamtu#3 0x55d419 in add_flow_init ofproto/ofproto.c:5123:17
williamtu#4 0x54841f in ofproto_flow_mod_init ofproto/ofproto.c:7987:17
williamtu#5 0x543250 in handle_flow_mod__ ofproto/ofproto.c:6206:13
williamtu#6 0x56a2fc in handle_flow_mod ofproto/ofproto.c:6190:17
williamtu#7 0x565bda in handle_single_part_openflow ofproto/ofproto.c:8504:16
williamtu#8 0x540b25 in handle_openflow ofproto/ofproto.c:8685:21
williamtu#9 0x6697fd in ofconn_run ofproto/connmgr.c:1329:13
williamtu#10 0x668e6e in connmgr_run ofproto/connmgr.c:356:9
williamtu#11 0x53f1bc in ofproto_run ofproto/ofproto.c:1890:5
williamtu#12 0x4ead0c in bridge_run__ vswitchd/bridge.c:3250:9
williamtu#13 0x4e9bc8 in bridge_run vswitchd/bridge.c:3309:5
williamtu#14 0x51c072 in main vswitchd/ovs-vswitchd.c:127:9
williamtu#15 0x7f23a99011a2 in __libc_start_main (/lib64/libc.so.6)
Uninitialized value was created by an allocation of 'ofpacts_stub'
in the stack frame of function 'handle_flow_mod'
#0 0x569e80 in handle_flow_mod ofproto/ofproto.c:6170
This could cause issues with flow modifications or other operations.
To reproduce, some NSH tests could be run under valgrind or clang
MemorySantizer. Ex. "nsh - md1 encap over a veth link" test.
Fix that by clearing padding bytes while encoding and decoding.
OVS will still accept OF messages with non-zero padding from
controllers.
New tests added to tests/ofp-actions.at.
Fixes: 1fc11c5 ("Generic encap and decap support for NSH")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Acked-by: Jan Scheurich <jan.scheurich@ericsson.com>
PlumeTomi
pushed a commit
to PlumeTomi/ovs-ebpf
that referenced
this issue
Aug 8, 2021
If datapath flow doesn't have one of the fields of gtpu metadata, e.g.
'tunnel(gtpu())', uninitialized stack memory will be used instead.
==3485429==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x853a1b in format_u8x lib/odp-util.c:3474:13
williamtu#1 0x86ee9c in format_odp_tun_gtpu_opt lib/odp-util.c:3713:5
williamtu#2 0x86a099 in format_odp_tun_attr lib/odp-util.c:3973:13
williamtu#3 0x83afe6 in format_odp_key_attr__ lib/odp-util.c:4179:9
williamtu#4 0x838afb in odp_flow_format lib/odp-util.c:4563:17
williamtu#5 0x738422 in log_flow_message lib/dpif.c:1750:5
williamtu#6 0x738e2f in log_flow_put_message lib/dpif.c:1784:9
williamtu#7 0x7371a4 in dpif_operate lib/dpif.c:1377:21
williamtu#8 0x7363ef in dpif_flow_put lib/dpif.c:1035:5
williamtu#9 0xc7aab7 in dpctl_put_flow lib/dpctl.c:1171:13
williamtu#10 0xc65a4f in dpctl_unixctl_handler lib/dpctl.c:2701:17
williamtu#11 0xaaad04 in process_command lib/unixctl.c:308:13
williamtu#12 0xaa87f7 in run_connection lib/unixctl.c:342:17
williamtu#13 0xaa842e in unixctl_server_run lib/unixctl.c:393:21
williamtu#14 0x51c09c in main vswitchd/ovs-vswitchd.c:128:9
williamtu#15 0x7f88344391a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
williamtu#16 0x46b92d in _start (vswitchd/ovs-vswitchd+0x46b92d)
Uninitialized value was stored to memory at
#0 0x87da17 in scan_gtpu_metadata lib/odp-util.c:5221:27
williamtu#1 0x874588 in parse_odp_key_mask_attr__ lib/odp-util.c:5862:9
williamtu#2 0x83ee14 in parse_odp_key_mask_attr lib/odp-util.c:5808:18
williamtu#3 0x83e8b5 in odp_flow_from_string lib/odp-util.c:6065:18
williamtu#4 0xc7a4f3 in dpctl_put_flow lib/dpctl.c:1145:13
williamtu#5 0xc65a4f in dpctl_unixctl_handler lib/dpctl.c:2701:17
williamtu#6 0xaaad04 in process_command lib/unixctl.c:308:13
williamtu#7 0xaa87f7 in run_connection lib/unixctl.c:342:17
williamtu#8 0xaa842e in unixctl_server_run lib/unixctl.c:393:21
williamtu#9 0x51c09c in main vswitchd/ovs-vswitchd.c:128:9
williamtu#10 0x7f88344391a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
Uninitialized value was created by an allocation of 'msgtype_ma' in the
stack frame of function 'scan_gtpu_metadata'
#0 0x87d440 in scan_gtpu_metadata lib/odp-util.c:5187
Fix that by initializing fields to all zeroes by default.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21426
Fixes: 3c6d05a ("userspace: Add GTP-U support.")
Acked-by: Yi Yang <yangyi01@inspur.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
PlumeTomi
pushed a commit
to PlumeTomi/ovs-ebpf
that referenced
this issue
Aug 8, 2021
While decoding RAW_ENCAP action, decode_ed_prop() might re-allocate
ofpbuf if there is no enough space left. However, function
'decode_NXAST_RAW_ENCAP' continues to use old pointer to 'encap'
structure leading to write-after-free and incorrect decoding.
==3549105==ERROR: AddressSanitizer: heap-use-after-free on address
0x60600000011a at pc 0x0000005f6cc6 bp 0x7ffc3a2d4410 sp 0x7ffc3a2d4408
WRITE of size 2 at 0x60600000011a thread T0
#0 0x5f6cc5 in decode_NXAST_RAW_ENCAP lib/ofp-actions.c:4461:20
williamtu#1 0x5f0551 in ofpact_decode ./lib/ofp-actions.inc2:4777:16
williamtu#2 0x5ed17c in ofpacts_decode lib/ofp-actions.c:7752:21
williamtu#3 0x5eba9a in ofpacts_pull_openflow_actions__ lib/ofp-actions.c:7791:13
williamtu#4 0x5eb9fc in ofpacts_pull_openflow_actions lib/ofp-actions.c:7835:12
williamtu#5 0x64bb8b in ofputil_decode_packet_out lib/ofp-packet.c:1113:17
williamtu#6 0x65b6f4 in ofp_print_packet_out lib/ofp-print.c:148:13
williamtu#7 0x659e3f in ofp_to_string__ lib/ofp-print.c:1029:16
williamtu#8 0x659b24 in ofp_to_string lib/ofp-print.c:1244:21
williamtu#9 0x65a28c in ofp_print lib/ofp-print.c:1288:28
williamtu#10 0x540d11 in ofctl_ofp_parse utilities/ovs-ofctl.c:2814:9
williamtu#11 0x564228 in ovs_cmdl_run_command__ lib/command-line.c:247:17
williamtu#12 0x56408a in ovs_cmdl_run_command lib/command-line.c:278:5
williamtu#13 0x5391ae in main utilities/ovs-ofctl.c:179:9
williamtu#14 0x7f6911ce9081 in __libc_start_main (/lib64/libc.so.6+0x27081)
williamtu#15 0x461fed in _start (utilities/ovs-ofctl+0x461fed)
Fix that by getting a new pointer before using.
Credit to OSS-Fuzz.
Fuzzer regression test will fail only with AddressSanitizer enabled.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27851
Fixes: f839892 ("OF support and translation of generic encap and decap")
Acked-by: William Tu <u9012063@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
when doing iperf between VMs.
The text was updated successfully, but these errors were encountered: