pinctrl: Use correct IPv6 dst for nd_ns action for IPv4 over v6.#3
Open
numansiddique wants to merge 1 commit into
Open
pinctrl: Use correct IPv6 dst for nd_ns action for IPv4 over v6.#3numansiddique wants to merge 1 commit into
numansiddique wants to merge 1 commit into
Conversation
If a logical router with dynamic-routing enabled learns a route
whose nexthop is an IPv6 address, then ovn-northd adds a logical
flow in the lr_in_ip_routing stage, but it doesn't add the
priority-200 logical flow in lr_in_arp_request to resolve the
mac of the nexthop. The below prioroty-100 logical flow gets invoked
instead.
table=27(lr_in_arp_request ), priority=100 ,
match=(eth.dst == 00:00:00:00:00:00 && reg9[9] == 0),
action=(nd_ns { nd.target = xxreg0; output; }; next;)
And this doesn't set the correct Solicit IPv6 destination address.
This patch fixes the issue in pinctrl handler function for nd_ns
action by using the IPv6 destination address stored in xxreg0.
This action assumes that xxreg0 is populated with the proper address.
Other alternative fix is for ovn-northd to add a logical flow
in lr_in_arp_request just like it adds for static routes.
I think its better to fix it in pinctrl instead.
Found this issue while testing dynamic routing feature.
Fixes: bcba1b7 ("pinctrl: Handle arp/nd for other address families.").
Assisted-by: Claude Opus 4.7, Claude Code
Signed-off-by: Numan Siddique <numans@ovn.org>
numansiddique
pushed a commit
that referenced
this pull request
May 15, 2026
When running a sequence of commands out of which some fail the
prerequisites check, ovn-dbctl didn't completely initialize the rest
of the commands. This in turn caused the cleanup code to try to
access random memory.
Caught by AddressSanitizer when running:
ovn-nbctl -- set logical_switch_port ln tag-request 100 -- show
==1857349==ERROR: AddressSanitizer: SEGV on unknown address (...)
==1857349==The signal is caused by a READ memory access.
==1857349==Hint: this fault was caused by a dereference of a high value address...
#0 0x000000403d5b in __asan::Allocator::Deallocate(...)
#1 0x0000004a4a9f in free (utilities/ovn-nbctl+0x4a4a9f)
#2 0x00000095855b in ds_destroy ovs/lib/dynamic-string.c:371:5
#3 0x0000004ea6e1 in ovn_dbctl_main utilities/ovn-dbctl.c:246:13
ovn-org#4 0x0000004f5bee in main utilities/ovn-nbctl.c:9096:12
ovn-org#5 0x7fe6873e5574 in __libc_start_call_main (/lib64/libc.so.6+0x3574)
ovn-org#6 0x7fe6873e5627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627)
ovn-org#7 0x0000004011c4 in _start (utilities/ovn-nbctl+0x4011c4)
Fixes: 8fb54e1 ("ovn-nbctl: Cleanup allocated memory to keep valgrind happy.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ales Musil <amusil@redhat.com>
(cherry picked from commit 45d7831)
numansiddique
pushed a commit
that referenced
this pull request
May 15, 2026
When running a sequence of commands out of which some fail the
prerequisites check, ovn-dbctl didn't completely initialize the rest
of the commands. This in turn caused the cleanup code to try to
access random memory.
Caught by AddressSanitizer when running:
ovn-nbctl -- set logical_switch_port ln tag-request 100 -- show
==1857349==ERROR: AddressSanitizer: SEGV on unknown address (...)
==1857349==The signal is caused by a READ memory access.
==1857349==Hint: this fault was caused by a dereference of a high value address...
#0 0x000000403d5b in __asan::Allocator::Deallocate(...)
#1 0x0000004a4a9f in free (utilities/ovn-nbctl+0x4a4a9f)
#2 0x00000095855b in ds_destroy ovs/lib/dynamic-string.c:371:5
#3 0x0000004ea6e1 in ovn_dbctl_main utilities/ovn-dbctl.c:246:13
ovn-org#4 0x0000004f5bee in main utilities/ovn-nbctl.c:9096:12
ovn-org#5 0x7fe6873e5574 in __libc_start_call_main (/lib64/libc.so.6+0x3574)
ovn-org#6 0x7fe6873e5627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627)
ovn-org#7 0x0000004011c4 in _start (utilities/ovn-nbctl+0x4011c4)
Fixes: 8fb54e1 ("ovn-nbctl: Cleanup allocated memory to keep valgrind happy.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ales Musil <amusil@redhat.com>
(cherry picked from commit 45d7831)
numansiddique
pushed a commit
that referenced
this pull request
May 15, 2026
In some scenarios, op->list is not attached anywhere, which makes attempts to detach it trigger ubsan failure. ovn/ovs/include/openvswitch/list.h:252:17: runtime error: member access within null pointer of type 'struct ovs_list' #0 0x?? in ovs_list_remove ovn/ovs/include/openvswitch/list.h:252:17 #1 0x?? in ovn_port_allocate_key ovn/northd/northd.c:4021:13 #2 0x?? in ls_port_init ovn/northd/northd.c:4321:10 #3 0x?? in ls_port_create ovn/northd/northd.c:4342:10 ovn-org#4 0x?? in ls_handle_lsp_changes ovn/northd/northd.c:4511:18 ovn-org#5 0x?? in northd_handle_ls_changes ovn/northd/northd.c:4655:14 ovn-org#6 0x?? in northd_nb_logical_switch_handler ovn/northd/en-northd.c:150: This patch makes northd use op->list only as a temporary means for build_ports logic to track ports that are persisted in both, nb, or sb only. Now build_ports will always detach ops once done. Now that op->list is never left attached to a list, we can remove ovs_list_remove calls for it elsewhere, including where op was never attached in the first place. Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com> Signed-off-by: Numan Siddique <numans@ovn.org> Acked-by: Mark Michelson <mmichels@redhat.com> (cherry picked from commit db4ea9d) Acked-by: Numan Siddique <numans@ovn.org> Acked-by: Ales Musil <amusil@redhat.com> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
numansiddique
added a commit
that referenced
this pull request
May 15, 2026
Commit 8d13579 creates a chassisredirect port for a logical switch port (of type 'router') in certain scenarios and 'op->nbsp' can be NULL. The following crash is reported by Sanitizer. ==84927==ERROR: AddressSanitizer: SEGV on unknown address ==84927==The signal is caused by a READ memory access. ==84927==Hint: address points to the zero page. #0 0x57ab3854f04a in hmap_first_with_hash ovn/ovs/./include/openvswitch/hmap.h:360:38 #1 0x57ab3854fedf in smap_find__ ovn/ovs/lib/smap.c:421:5 #2 0x57ab3854f7b8 in smap_get_node ovn/ovs/lib/smap.c:217:12 #3 0x57ab3854f74f in smap_get_def ovn/ovs/lib/smap.c:208:30 ovn-org#4 0x57ab3854f726 in smap_get ovn/ovs/lib/smap.c:200:12 ovn-org#5 0x57ab3854f862 in smap_get_int ovn/ovs/lib/smap.c:240:25 ovn-org#6 0x57ab383222eb in ovn_port_assign_requested_tnl_id ovn/northd/northd.c:4372:27 ovn-org#7 0x57ab383072fa in build_ports ovn/northd/northd.c:4454:9 ovn-org#8 0x57ab38301457 in ovnnb_db_run ovn/northd/northd.c:18023:5 ovn-org#9 0x57ab3841d99e in en_northd_run ovn/northd/en-northd.c:137:5 ovn-org#10 0x57ab384599b2 in engine_recompute ovn/lib/inc-proc-eng.c:411:5 ovn-org#11 0x57ab38459d6e in engine_run_node ovn/lib/inc-proc-eng.c:473:9 ovn-org#12 0x57ab38459ec3 in engine_run ovn/lib/inc-proc-eng.c:524:9 ovn-org#13 0x57ab38430c5d in inc_proc_northd_run ovn/northd/inc-proc-northd.c:420:5 ovn-org#14 0x57ab3841bb2f in main ovn/northd/ovn-northd.c:970:32 This patch fixes this issue. It also corrects some typo introduced by the commit - changes the reference from "chassisresident" to "chassisredirect". Fixes: 8d13579 ("Add support for centralize routing for distributed gw ports.") Reported-by: Felix Huettner <felix.huettner@mail.schwarz> Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2024-August/416264.html Acked-by: Han Zhou <hzhou@ovn.org> Signed-off-by: Numan Siddique <numans@ovn.org> (cherry picked from commit 9fbda4a) Acked-by: Numan Siddique <numans@ovn.org> Acked-by: Ales Musil <amusil@redhat.com> Signed-off-by: Dumitru Ceara <dceara@redhat.com>
numansiddique
pushed a commit
that referenced
this pull request
May 15, 2026
When running a sequence of commands out of which some fail the
prerequisites check, ovn-dbctl didn't completely initialize the rest
of the commands. This in turn caused the cleanup code to try to
access random memory.
Caught by AddressSanitizer when running:
ovn-nbctl -- set logical_switch_port ln tag-request 100 -- show
==1857349==ERROR: AddressSanitizer: SEGV on unknown address (...)
==1857349==The signal is caused by a READ memory access.
==1857349==Hint: this fault was caused by a dereference of a high value address...
#0 0x000000403d5b in __asan::Allocator::Deallocate(...)
#1 0x0000004a4a9f in free (utilities/ovn-nbctl+0x4a4a9f)
#2 0x00000095855b in ds_destroy ovs/lib/dynamic-string.c:371:5
#3 0x0000004ea6e1 in ovn_dbctl_main utilities/ovn-dbctl.c:246:13
ovn-org#4 0x0000004f5bee in main utilities/ovn-nbctl.c:9096:12
ovn-org#5 0x7fe6873e5574 in __libc_start_call_main (/lib64/libc.so.6+0x3574)
ovn-org#6 0x7fe6873e5627 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x3627)
ovn-org#7 0x0000004011c4 in _start (utilities/ovn-nbctl+0x4011c4)
Fixes: 8fb54e1 ("ovn-nbctl: Cleanup allocated memory to keep valgrind happy.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ales Musil <amusil@redhat.com>
(cherry picked from commit 45d7831)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If a logical router with dynamic-routing enabled learns a route whose nexthop is an IPv6 address, then ovn-northd adds a logical flow in the lr_in_ip_routing stage, but it doesn't add the priority-200 logical flow in lr_in_arp_request to resolve the mac of the nexthop. The below prioroty-100 logical flow gets invoked instead.
table=27(lr_in_arp_request ), priority=100 ,
match=(eth.dst == 00:00:00:00:00:00 && reg9[9] == 0),
action=(nd_ns { nd.target = xxreg0; output; }; next;)
And this doesn't set the correct Solicit IPv6 destination address.
This patch fixes the issue in pinctrl handler function for nd_ns action by using the IPv6 destination address stored in xxreg0. This action assumes that xxreg0 is populated with the proper address.
Other alternative fix is for ovn-northd to add a logical flow in lr_in_arp_request just like it adds for static routes.
I think its better to fix it in pinctrl instead.
Found this issue while testing dynamic routing feature.
Fixes: bcba1b7 ("pinctrl: Handle arp/nd for other address families.").
Assisted-by: Claude Opus 4.7, Claude Code