Some openflow actions can be misaligned, e.g., actions whithin OF 1.0
replies to statistics reply messages which have a header of 12 bytes
and no additional padding.
Also, buggy controllers might incorrectly encode actions.
When decoding multiple actions in ofpacts_decode(), make sure that
when advancing to the next action it will be properly aligned
(multiple of OFPACT_ALIGNTO).
Detected by UB Sanitizer when running one of the fuzz tests:
lib/ofp-actions.c:5347:12:
runtime error: member access within misaligned address 0x0000016ba274
for type 'const struct nx_action_learn', which requires 8 byte alignment
0x0000016ba274: note: pointer points here
20 20 20 20 ff ff 00 38 00 00 23 20 00 10 20 20
^
20 20 20 20 20 20 20 20 20 20 20 20 00 03 20 00
0 0x52cece in decode_LEARN_common lib/ofp-actions.c:5347
1 0x52dcf6 in decode_NXAST_RAW_LEARN lib/ofp-actions.c:5463
2 0x548604 in ofpact_decode lib/ofp-actions.inc2:4723
3 0x53ee43 in ofpacts_decode lib/ofp-actions.c:7781
4 0x53efc1 in ofpacts_pull_openflow_actions__ lib/ofp-actions.c:7820
5 0x5409e1 in ofpacts_pull_openflow_instructions lib/ofp-actions.c:8396
6 0x5608a8 in ofputil_decode_flow_stats_reply lib/ofp-flow.c:1100
Acked-by: Adrian Moreno <amorenoz@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This is undefined behavior and was reported by UB Sanitizer:
lib/meta-flow.c:3445:16: runtime error:
member access within null pointer of type 'struct vl_mf_field'
0 0x6aad0f in mf_get_vl_mff lib/meta-flow.c:3445
1 0x6d96d7 in mf_from_oxm_header lib/nx-match.c:260
2 0x6d9e2e in nx_pull_header__ lib/nx-match.c:341
3 0x6daafa in nx_pull_header lib/nx-match.c:488
4 0x6abcb6 in mf_vl_mff_nx_pull_header lib/meta-flow.c:3605
5 0x73b9be in decode_NXAST_RAW_REG_MOVE lib/ofp-actions.c:2652
6 0x764ccd in ofpact_decode lib/ofp-actions.inc2:4681
[...]
lib/sset.c:315:12: runtime error: applying zero offset to null pointer
0 0xcc2e6a in sset_at_position lib/sset.c:315:12
1 0x5734b3 in port_dump_next ofproto/ofproto-dpif.c:4083:20
[...]
lib/ovsdb-data.c:2194:56:
runtime error: applying zero offset to null pointer
0 0x5e9530 in ovsdb_datum_added_removed lib/ovsdb-data.c:2194:56
1 0x4d6258 in update_row_ref_count ovsdb/transaction.c:335:17
2 0x4c360b in for_each_txn_row ovsdb/transaction.c:1572:33
[...]
lib/ofpbuf.c:440:30:
runtime error: applying zero offset to null pointer
0 0x75066d in ofpbuf_push_uninit lib/ofpbuf.c:440
1 0x46ac8a in ovnacts_parse lib/actions.c:4190
2 0x46ad91 in ovnacts_parse_string lib/actions.c:4208
3 0x4106d1 in test_parse_actions tests/test-ovn.c:1324
[...]
lib/ofp-actions.c:3205:22:
runtime error: applying non-zero offset 2 to null pointer
0 0x6e1641 in set_field_split_str lib/ofp-actions.c:3205:22
[...]
lib/tnl-ports.c:74:12:
runtime error: applying zero offset to null pointer
0 0xceffe7 in tnl_port_cast lib/tnl-ports.c:74:12
1 0xcf14c3 in map_insert lib/tnl-ports.c:116:13
[...]
ofproto/ofproto.c:8905:16:
runtime error: applying zero offset to null pointer
0 0x556795 in eviction_group_hash_rule ofproto/ofproto.c:8905:16
1 0x503f8d in eviction_group_add_rule ofproto/ofproto.c:9022:42
[...]
Also, it's valid to have an empty ofpact list and we should be able to
try to iterate through it.
UB Sanitizer report:
include/openvswitch/ofp-actions.h:222:12:
runtime error: applying zero offset to null pointer
0 0x665d69 in ofpact_end ./include/openvswitch/ofp-actions.h:222:12
1 0x66b2cf in ofpacts_put_openflow_actions lib/ofp-actions.c:8861:5
2 0x6ffdd1 in ofputil_encode_flow_mod lib/ofp-flow.c:447:9
[...]
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If enough large input is given ofpact_finish will fail.
Implemented ofpbuf_oversized function to check for oversized
buffer. Checks were added for parse functions and error messages
returned.
Basic manual testing performed.
Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com>
Reported-by: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12972
Signed-off-by: Toms Atteka <cpp.code.lv@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This assertion was removed as part of a commit that was intended to
just be a cleanup.
Fixes: 6fd6ed71cb9f ("ofpbuf: Simplify ofpbuf API.")
Acked-by: Justin Pettit <jpettit@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Clang 4.0 complains:
In file included from include/openvswitch/cxxtest.cc:11:0:
../include/openvswitch/ofpbuf.h: In function ‘ofpbuf ofpbuf_const_initializer(const void*, size_t)’:
../include/openvswitch/ofpbuf.h:107:5: warning: narrowing conversion of ‘size’ from ‘size_t {aka long unsigned int}’ to ‘uint32_t {aka unsigned int}’ inside { } [-Wnarrowing]
};
^
../include/openvswitch/ofpbuf.h:107:5: warning: narrowing conversion of ‘size’ from ‘size_t {aka long unsigned int}’ to ‘uint32_t {aka unsigned int}’ inside { } [-Wnarrowing]
This is because the ofpbuf struct's "size" parameter is a uint32_t,
while ofpbuf_const_initializer() takes a size_t for the size. Fix this
function to take a uint32_t instead.
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
